..but then they kept adding. And adding. And adding. And adding.. and now where are we? Death by a thousand cuts. 10x the complexity for an additional 7% benefit

Not sure I fully understand the second bit. Given how much more powerful servers are now (both physical and abstracted) doesn't that vertical scaling mean horizontal scaling is less necessary? If horizontal scaling is necessary, depending on where in the stack you're scaling, the global consistency offered by modern cloud data stores make it more efficient than ever for lots of servers to exchange a session cookie for state and return fully rendered HTML.

I agreed it makes it harder in places. Like when I (as a be dev) have to write JS hooks, or the JS dev's on the team have to interact with the database.

I find I'd rather code in a RESTfull code base than a socket system. I miss the lines.

This leads me to question why people still use jQuery instead of native JavaScript. From my understanding, jQuery primarily serves as a polyfill. So why jQuery and not native Javascript?

In JavaScript, it is not. So you claiming 10 years as a time frame in your response is in bad faith, because you certainly know that code written 10 years ago is 100% incompatible with the modern versions of the same frameworks.

Well, that’s all I needed to hear. What’s the point of not sounding old-fashioned when the new fashion is worse? Considering the social point, why not be more critical when the efficient and reasonable thing is derided by others as old-fashioned? Why not expect those people to update their world view?

Small companies are great - but in the general job market, when you propose an idea that is not inline with the higher ups in the company, it quickly becomes a matter of ego and hate, even if it is the right idea.

For web components, I utilize Lit for its syntactic sugar and because I appreciate the decorator approach. Since browser compatibility is typically not an issue in these projects, I leverage native CSS 3 features and avoid using SCSS as a polyfill for nesting, variables, and maintaining DRY principles.

I haven't heard of Mithril before. Thanks for sharing!

I didn’t say you would like it. I just said a build system is not required, contrary to what you wrote. JSX is not an integral part of React, and it is practical to omit it for small cases where interactivity is needed. Contrast it with things like Vue, Qwik, Astro, etc.

> I know it's an unpopular opinion (and the React people swear it's not true) but React is absolutely a framework, not a library

On the contrary, I think it is a very widespread opinion (most of this site will probably claim the same, and opposing comments are often downvoted), but that doesn’t make it less wrong. People form their opinion from encountering various instances of React use in the wild and common patterns of using React, not from what React actually is. Those instances or patterns will necessarily be mostly bad because the barrier of entry to Web development is very low and with LLMs the amount of that bad code only multiplies as of late.

> Adding React to a project fundamentally changes how that project is architected, and affects almost all of the code written for that project going forward.

By that logic, something like fp-ts or Effect is a framework, rather than a set of tools for functional TypeScript programming.

An important quality of a framework is that “you are building within its realm”. Consider Django. You have project scaffolding and structure, batteries are included, and the way you use it is strongly prescriptive or you are fighting the framework.

By contrast, like the above-mentioned Effect, React prescribes little and can be used in vastly different ways and applications not limited to Web. React itself does not even depend on there being DOM or browser context of any kind, I think last I checked it actually had no Web-specific code at all, though I don’t know if RSC changed that. All DOM-related stuff comes from ReactDOM, which is another library.

> Trying to use it just as a library very much goes against the grain of how it is commonly used.

First, if most people use it wrong[0], then just go against that grain. It will not go against React’s grain, because it has not much grain to speak of. It is a library with a few restrictions about what kind of callbacks you pass it.

Second, React is most commonly used through frameworks, like Next.js and such. There are also many instances of people using React via CRA project templates, which again are not part of React proper.

[0] …and using a library as if it was a framework is most definitely wrong. If your use case is of the framework-fitting scale, you should either A) use a framework or B) be conscious of the fact that you will end up with a framework of your own and plan accordingly (by default those frameworks tend to suck).