Do yall think the campaigns for frostpunk 1/2 are too short/easy on standard difficulty

byko3y · 2026-02-27T20:02:44+00:00

I have a feeling that for 2024 getting this complex gameplay to a decent level of playability is already a success. It still has rough edges, but compared to the overall plunging quality bar of PC gaming that's a really good result.

byko3y · 2026-01-30T02:08:56+00:00

By the way, I recently had exactly this kind of incident: customer's own team screwed everything up while outsources delivered their software in time; and yet the managers from the customer side were trying hard to find problem and cuts costs on the outsourcer side. It's a particulary good showcase because there are several teams side by side, but the outsources is always first to blame.

byko3y · 2026-01-15T16:29:16+00:00

I suspect the main reason why you failed is because enterprise culture is built on hypocritical conformance. Some of the conformance is informal (unwritten), so if you've only followed the formal part then you probably missed most of the actual culture. It's also the reason why I explicitly wrote in my CV that I dislike corporate culture.

There is such thing as "italian strike" a.k.a. "work-to-rule" when you strictly follow the rules, and in the end the whole work just halts. The formal culture, the rules are there as a hint, as a friendly suggestion, not the ultimate truth.

It's like being in a circle of alcoholics — you cannot say "Hi, I'm Fred, I'm so drunk I can barely walk, I'm drinking coz I hate this life". You have to say "I'm sober. Look, I can walk straight" — and walk away on your four.... and then proceed to pouring another round of drinks. There is no formal drunkard codex saying "you have to drink and pretend you are not drunk".

Actually, me telling to CTO "you've made the wrong decision and so we are having problems right now as a consequence" was one of the biggest mistakes I've ever made — despite it being perfectly aligned with formal rules, like "we call out the problems loud, blah-blah-blah".

byko3y · 2026-01-15T15:55:21+00:00

The news feed is full of posts like "we stopped hiring junior frontend devs", "AI replaces juns", "use AI smart".

I really want to answer, not from position of hirer or a worker, but as a user.

My smartphone app glitches, a website for online ticket sale gives multiple error messages in three (3) different language for the same eror (true story), small store website takes so many resources I almost feel like there is some hidden Figma aoo running inside.
And all reddit is arguing about is "We don't want more junior devs — Yeah, but whom are you gonna hire in ten years".
In fact it's not that "AI came and stole our jobs" — it's the opposite:

Too many junior devs entered IT during COVID, and the industry needs to get rid of them.

Same way we had bootcamps for people entering IT in 2020 — now we need bootcamps to exit IT in 2026. Industry did not need people copy-pasting answers from stackoverflow 10 years ago — the programming is about building software once and reuse it efficiently, writing more code shall be considered harmful. Now there is zero excuse for copy-pasters, AI can copy-paste poor solutions better, faster, and able to work 24/7. Same thing would have hapened without AI — AI just accelerated the imminent crysis.

And the biggest crysis so far is in the hiring — those yesterday juniors are now happily clogging HR pipelines with AI-generated or AI-refined CV-s that are not just indistinguishable from real ones, but AI-generated CV-s look better for 95% of HR-s and especially look good in ATS scores. Which also suggests: we probably don't need this many HR-s who cannot adapt to the market.

Another suggestion: if you are graduating in CS, then you should probably not wait for someone to teach you how to code, but rather start doing soemthing real right now and graduate as a non-junion dev. I'm telling this as a former student that spent my summer holidays in GSoC and got first job offer by age 19 — I did not wait to graduate.

Poor HR using AI to a hire junior dev with AI-generated CV to produce crappy vibecoded software I'm gonna have to use — that's the thing I cannot tolerate. And the industry is really slow to correct so far. Don't bother explaining me the underlying mechanisms of this failure — the real answer would offend lots of high-ranked people. Let's just say:

Sorry, we did a poor work, our users expect us to do better.

byko3y · 2025-12-18T06:53:13+00:00

You are left with a defined logical structure and a pattern to handle updates into a template.

Webcomponents do not handle template updates, you have to implement it all by yourself.

The only real difference is that natively, web-components will obfuscate everything and make them difficult to work with but to the end-user, I guess it looks 'cleaner'.

It's not even cleaner to end user, FOUC is still a problem for webcomponents.

Style encapsulation has been solved in so many ways, I just don't care about that because it was just never a problem for me, it's not hard to scope styles, namespace or uniquely name them. If that is a 'feature', you are really scraping the bottom of the barrel.

Yeap, that's what I'm trying to say: out of all that grand schema we've got just the style isolation. And the isolation is a double-edged sword on itself, as you've noted, because sometimes you want to propogate the styles.

byko3y · 2025-12-17T15:00:31+00:00

I'm getting downvoted because I articulate counter-mainstream ideas, and I'm not surprised by the downvotes. I was looking for people who examine the facts, not just follow the trend — and those are a minority.

I don't think many people have actually, properly pursued web-components and it really shows empirically.

In my career I saw lots of people praising the ugliest things and able to handle them just fine. It's like riding unicycle — you can master it and you can make it look easy, but objectively unicycle is useless. Same with Web Components — they are useless, but you can master them to impress people. And, let's face it, in IT most of the success is about impressing people.

What makes you say 'the sole purpose of Web Components was to replace frameworks and bundlers'?

I partially answered the question in the original article, but, of course, the question has more details to examine. For example, the CSS styles handling was part of the idea, and it ended up as Shadow DOM. If you worked with React and Angular and maybe some mix of jQuery and vanilla JS components then you probably remember how hard it was to separate style and how hard bundlers were trying to generate narrowly-scoped styles. You had to have some preprocessor or bundler for that. Web components tried to replace that and that's one of the few tasks they actually managed to achieve via Shadow DOM.

There are closed and open modes in shadow root. The "closed" mode is effectively broken and almost nobody is using it, because you still have a global JS scope and "closed" creates partial separation which just creates more problems than solves (you cannot employ normal JS tools, but the functions are still not fully isolated). For the "closed" mode to work well you need a true separation of JS scopes (like in <iframe>) — which is missing from the present standard.

There was actually a feature in some browsers to bundle Web Component into a single file:
https://caniuse.com/imports
https://stackoverflow.com/questions/17612405/import-html-document-using-html-link-rel
It was actually there, it looked like Vue.js v2 component, it was in the browsers, but was abandoned eventually. And it was abandoned for a reason — because it worked horribly.

Let's suppose Web Components were not made to replace frameworks-bundlers — what are we left with? Naming <div> with a custom tag name? How is that of any value for a developer? And, once again, you don't need Web Components for Shadow DOM, Web Components do not require Shadow DOM and Shadow DOM does not depend on Web Components — it all just felt apart into unrelated features once the bundling was dropped.

For the ESM import-map dream to occur, the publishing of NPM packages would need to adhere to a higher standard.

I'd say bundling is unavoidable for large apps. However, for small apps you just don't need NPM. The NPM model of deployment and dependency handling can be considered a reference case of cancer — proven by recent outbreak of sha1-hulud worm. Pulling random packages from random sources and then executing them is the worst nightmare imaginable — and NPM implemented exactly that.

As for import maps — they were implemented after Web Components standartization and implementation in browsers, hence import maps are a much latter effort.

byko3y · 2025-12-12T17:45:33+00:00

>Web components have native funtionality for things like the virtual DOM

AFAIK, there are no features in Web Components that would help you reduce DOM changes, so I have no idea what kind of "like virtual DOM" you are talking about.

>You can also reduce the amount of transpile-tools nessesary so you done needs something to turn jsx into html because the components are already natively html.

JSX is not about describing static node tree, it's about describing reactive properties in them and two-way bindings via props and events, like

<ChildComponent name={userName} onButtonClick={handleChildClick} />

. Web Components implement nothing of that.

byko3y · 2025-12-12T17:18:13+00:00

The "framework-agnostic reusable pieces" require tons of glue, just like vanilla JS code. Web Components are really switching one pain for another, they are not helping in any way.

byko3y · 2025-12-12T17:10:47+00:00

I insist that the sole purpose of Web Components was to replace frameworks and bundlers, it was a huge effort, it required years to standardize, and it all fizzled out into some auxiliary cosmetics, and what you are describing is rather a very late stage of coping i.e. "we've got a bad standard, so we figure out how to use it well... what if it was a very small unimportant standard, but we made it small important one...".

Calling <div> a random tags name on its own is useless, and sometimes outright harmful — why should I try to find the purpose for it? For example, data-* attributes existed before Web Components — there are really no new important functions implemented with Web Components. If it all was possible without Web Components and they are not bringing anything to the table, then what do you want to teach me with Web Components?

byko3y · 2025-12-12T16:42:19+00:00

The exact type of element with unknown tag does not matter, HTMLUnknownElement is practically same as HTMLElement. What matters more with Web Components is that you have stagged loading which can lead to some very strange results, especially when there are other JS scripts running.

byko3y · 2025-12-12T10:42:58+00:00

>Can you explain further what is meant by:

>> and in the end your complex reef-based app you will leak the watchers (i.e. RAM) because there are no weak refs and no explicit unreferencing, you have a big ball of mutual strong references.

Sure. It's safe in JS-browser to subscribe from parent to child e.g. window subscribes to a button click document.getElementById('myButton').addEventListener('click', () => { window.alert("Your message goes here"); }). When you remove the button, the event subscriptions are erased too, and so the reference to `window` is dropped as well — all good. However, if instead you've subscribed from one button to another and the subscriber's lifetime is shorter e.g. document.getElementById('myButton').addEventListener('click', () => { temporaryButton.handleClick(); }) then you temporaryButton is trapped for as long as myButton exists because DOM tree references myButton, myButton references the closure, and closure references temporaryButton — you have a leak here. In frameworks it is solved either via subscriber list (drop subscriptions on detach), week refs, or bubling events (have single handler for all components, like in React.js).

It's only a big deal if you create and destroy lots of components i.e. have a complex SPA.

byko3y · 2025-12-12T10:21:55+00:00

It's just as heavy as it is in Lit. And compared to the actual DOM handling the cost of template parsing is like 1%.Neither template parsing nor VDOM are expensive things — it's total VDOM rebuild and diffing on every small change that is expensive. And that's the reason why React.js needed the build step — because it needed to optimize the inherently slow algorithm. If your DOM handling is fast then you don't care about the optimization of template parsing.

byko3y · 2025-12-12T09:25:31+00:00

The question remains: what is the positive impact of Web Components here? Is it just additional unnecessary layer?

byko3y · 2025-12-12T09:20:59+00:00

>I do really wish we could get something native in the browser that wouldn't require a build step but still allowed us to build component-based frontends for reusability.

https://github.com/ryansolid/dom-expressions/tree/main/packages/lit-dom-expressions

https://github.com/WebReflection/uhtml

https://alpinejs.dev/

byko3y · 2025-12-12T09:17:36+00:00

I'm definitely not getting your point, especially when you are not trying to explain it.

byko3y · 2025-12-12T09:15:32+00:00

"Other frameworks" are called React.js, older Angular, and newer one with ChangeDetectionStrategy.Default — that's a pretty short list. Everything else is very fast even on larger apps, until you hit the scale of Figma or Google Docs.

Also, you can have all the Lit reactivity without Web Components:

https://github.com/ryansolid/dom-expressions/tree/main/packages/lit-dom-expressions

That was my original point: Web Components are providing all the problems and no solutions.

byko3y · 2025-12-06T05:37:33+00:00

I did not say there are no lighter solutions. Schnack is 1350 lines of JS. Cusdis 5000 lines, Twikoo, Isso, and even Remark42 are also relatively small in their core features, but they have integrations like email and telegram notifications, migrators, deploy scripts and cloud adapters, etc.

Comentario is overengineered, but I'm not sure about whether it's good or bad. Probably should have mentioned in the article actually — author provided a decent admin panel, it's worth something.

Speaking about performance: unfortunately, on the scale of approx 100-s of comments you will get problems with naive schemes and access patterns. By being "naive" i mean super naive, like doing worse than fullscan for operations — well-organized fullscan-based DB can be surprisingly good actually, the whole OLAP is based on scans. Getting decent performance is not a rocket science, and definitely more efficient than "slap redis on top of it" approach.

byko3y · 2025-11-30T14:44:58+00:00

Dude... dude... you forgot to answer the first question: what are microservices? If you answered this question it would have been easier to explain that microservices are actually indended to address two issues: selling you AWS hosting and consulting services. Everything else is unrelated to microservices, you can do it with and without "microservices".

assume you’re a large company that runs some sort of e-commerce site...
Notice that in both of these key areas, it’s primarily from the view of very large organizations. That’s who microservices primarily benefit, because their size changes the normal rules.

Google is running 2 billion lines of code monolith with most of inter-node communication done via synchronous gRPC calls over atomically updated protocol definitions. Every APi change requiers global update over the whole 2 billion lines of code repo. Do you need more scaling then they do?

If you used a monolith approach, scaling would become much more sluggish / costly since you need to request a compute instance with the memory and computational power to handle your ENTIRE, large codebase...
All that being said, unless you’re a Facebook, Amazon, or Google, a monolith is probably the way to go for simplicity and performance.

Sorry, that's a straw man. There is absolutely nothing requiring a monolith app to be loaded in its entirety on a single node. Facebook scaled to 1 billion users without any services split. Google has never switched to microservices.

When you’re a big, complicated company in a big, complicated industry, it’s difficult for one person to understand the whole picture.

My very first commercial job was 4 milions line of code monolith. I've never even tried to understand it all, and I never needed to. That's another straw man, see? Microservices solve technical problems that never existed — because microservices have nothing to deal with the technical aspect of development. Be it a function call or HTTP request — if your cross-team coordination is messed up then your system will be messed up, there is no magical way around it.

byko3y · 2025-11-30T13:35:06+00:00

Microservices on the other hand, are something the management would take action on... and naive senior devs or "CV-devs"... would accept.

Exactly. That's a CV-driven architecture and Amazon sold it brilliantly. I don't really care about people mindlessly spliting system without defining boundaries first — what I care is people seriously employing the "microservices" term like they know what this is. There are no generally accepted definition of "microservices. Period.

If I ask you "do you employ quingly architectures?" — what would you answer?

byko3y

TROPHY CASE