Do you complain when other frameworks add new features without breaking backwards compatibility?

    > You can still use vanilla-OO React

Because it has such a huge marketshare, a fix like this would have tremendous positive effects in web dev.

If you search anything about React now, 90% of the docs are hook-based. Beginners of React in 2025 will be guided to use a default pattern which has worse runtime footprint and adds a whole suite of new tool-specific coding guidelines ("rules of hook"). After years with it, I struggle to see what it has added in terms of building front-end SPas, yet the pattern is now the default for all using React.

Can we please retire this meme? It's stale and adds nothing to the conversation.

    > Does that really matter to most companies/developers?

This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it.

But even outside of e-comm, consider government websites where you may have low income users that are using cheaper, older, lower capability devices to access information and services using lower speed networks to boot.

I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications.

    > ...with a large ecosystem built around it

In fact, you may be better off for not creating the added external dependency.

And you still pay a few cents extra in power used because of all those inefficient and memory hungry "applications". You just don't notice.

Also the react compiler is improving client side performance as well by automatically memo-izing everything to reduce rerenders

1) Trading memory pressure for performance

2) An admission of a broken model because it's taken them 2+ (almost 3?) years to build as a recognition that developers can't get it right

The reason other frameworks don't need this is because they use signals connected to callbacks instead of the reactive callback pointing to the component (as React does). Thus Preact, Solid, Svelte, Vue, etc. do not have this issue and you rarely (if ever?) have to manually memoize.

The React team foot-gunned themselves and every React dev out there.

I have some examples that walk through this concept using JSFiddle so you can understand exactly why this design choice from React created this problem in the first place: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...

Most places just don't care. I've worked 15 years as a contractor and only in once place have the business cared about optimisation. As long as it wasn't unbearable than it was "good enough".

> This is especially true in e-commerce where many studies have shown that overall page performance has a correlation to conversion. Add to that the fact that a lot of e-commerce has moved to mobile web, there's a strong case for picking the best performing technologies versus developer preference -- especially if AI is generating it.

This may have been true back in 2014. 5G networks are pretty fast and the the mobile web is pretty bloated. Performance is way down the list of concerns typically even by places that should care. I can write blazingly fast custom JS frameworks, the number of times anyone cares is exactly one time.

> I do my day-to-day work on an M3 Max with 64GB RAM and fiber to the home; it's easy for developers to forget that many times, their end users can be on older devices, on low performing networks, and other factors that affect performance and usability of web applications.

I have a 2010 Dell E6410 with 8GB of ram and an i7 640M (Dual Core, 4 thread). Almost every modern phone is faster now.

I am not arguing we should make things bloated. I am just saying there isn't an incentive to optimise for low end devices because low end is better than a reasonably power Business Laptop of 10-15 years ago.

> why would you waste time and energy to create your own calendar component? But if an LLM can generate any bespoke component that you need in < 3 seconds, do you still need a third party component library?

The code from the LLM probably hasn't been battle tested. The open source react component library with 1000s of stars on github definitely has been. If you run into a problem with the LLM code you are probably going to be by yourself fixing it. I will take the component library over the LLM code everyday of the week.

I wrote a very lightweight JS framework (it was just a few classes really) so we could have plugins. A plugin implemented was just an object that implemented an interface, I also wrote a poor man's React for two or three pages that needed to build a lot of DOM Dynamically.

At launch the site was getting basically 100 on the lighthouse tests with the gzipped CSS and JS coming it at ~80KB. Of course that lasted for a week because people will put up a huge image that hasn't been optimised for the web.

The site was fast because I wrote it like a website from mid-2000s. Everything was basic OOP and almost all the code was procedural.

If we were using svelte we would still have performance issues, but they would probably be centered more on "is the data in a sane shape such that this page can query it?"

Loads of libraries, documentation, and developers which creates a flywheel that will grow those aspects over the next X years.

Until something comes up that is magnitude better in performance/maintainability, and even then it’ll take years to dethrone the status quo.

Good questions in these comments essentially asking, does the level of training data on these models now contribute to the inertia we see from libraries, documentation, developer support?

I believe so, but then again I think we’ll soon have more niche models for specific areas of development (like openart has with a variety of image gen models)

Maintainability doesn't even enter the question. React's way is to rewrite. All of the alternatives on the GP's comment are possible to maintain.

Not comparable.

Java may not have had big releases during this time but there were patches and support. Java 8 had numerous versions (>400). You can get paid support from Sun/Oracle. In terms of frameworks Spring was constantly upgraded and supported.

React has none of these. Older React versions rarely get upgraded and just look at the amount of minor/patch releases React gets these days. It's almost as though Meta no longer cares. Earlier (<16) React was constantly updated. Nowadays it's just to peddle Vercel.

NGINX for my server though recently I ran into an out of connections problem that was new on an Azure VM

My personal opinion is that a lot of the hate directed at react is due to experiences with code bases that aren’t good react code.

It has the best ecosystem of libraries and it’s not even close.

If you write your web app in Vue and decide you want mobile apps later you won’t be able to share much code there.

Many, many (if not most) devs probably do not realize that React has an "inverted" model of reactivity and is in fact the root cause of it's performance woes.

To the extent that the React team spent 2+ (almost 3?) years working on a compiler to address the issue by adding in the correct memoization primitives in a compile phase (trading increased memory consumption for more runtime performance...).

I wrote about it here with code examples that work in JSFiddle: https://chrlschn.dev/blog/2025/01/the-inverted-reactivity-mo...

The short of it is that by pointing the reactive callback to the component function, it means that state within the component function has to be managed carefully. This doesn't happen in Vanilla, Preact, Solid, Svelte, and Vue because they point the reactive callback (via "signals") to a handler function that captures the component state in a closure. This is also why they are all faster and consume less memory than React.

Because React points the reactive callback to the component function, it effectively starts from a clean slate each re-render so the purpose of React Hooks is to move state out and inject them back (thus they are called "hooks") when it re-renders. In Preact, this is not the case since it uses signals: https://preactjs.com/guide/v10/signals/

A short video of the same examples if you prefer: https://youtu.be/7OhyP8H7KW0

Preact is mostly API-compatible with React, and it having a different underlying model is an extraordinary claim that requires extraordinary evidence.

I've read the docs on Preact signals, and they look like React refs, but put outside of components.

edit: the last paragraph about refs

    > ...a different underlying model is an extraordinary claim that requires extraordinary evidence

The post doesn't need to mention Preact because every other framework is signals-based except for React. Vue is simply the stand-in for "signals-based reactivity". Vue has different syntax from Preact (though it, too, can also use JSX), but it has the same reactivity principle.

https://preactjs.com/guide/v10/signals/

    > What makes Signals unique is that state changes automatically update components and UI in the most efficient way possible. Automatic state binding and dependency tracking allows Signals to provide excellent ergonomics and productivity while eliminating the most common state management footguns.

Vue docs: https://vuejs.org/guide/extras/reactivity-in-depth.html#conn...

Solid docs: https://www.solidjs.com/docs/latest/api#createsignal

Svelte: https://svelte.dev/blog/runes#Signal-boost

Qwik docs: https://qwik.dev/docs/components/state/#usesignal

In the blog post, Vue is the stand-in for signals-based reactivity. All signals-based reactivity models work the same way at a high level (their difference being primarily in their low-level DOM diff and update).

My prediction is that even React will eventually end up signals based because of TC39 Signals: https://github.com/tc39/proposal-signals

But very clearly, Preact has the option of the exact same reactivity primitive and design as Vue, Solid, Qwik, and Svelte

https://preactjs.com/guide/v10/signals/

    > In Preact, when a signal is passed down through a tree as props or context, we're only passing around references to the signal. The signal can be updated without re-rendering any components, since components see the signal and not its value. This lets us skip all of the expensive rendering work and jump immediately to any components in the tree that actually access the signal's .value property.

That depends on who is writing it and what the app is. Most frontend code is written by people who don't have as much time to focus on performance and optimization as core framework developers, so their once their apps reach a critical mass of 'actually big enough to benefit from a framework' the app is worse than it would have been if it was written with a framework in the first place.

The problem for all of us, and where frameworks often make the web suck, is that very few apps are actually that big. Frontend developers love to put React in a page that has one form input a button, which is dumb.

I take that to be the point of the article: the bias towards React and of course the training data being stale means that generated code will always have a bit of staleness and as we provide less context for the AI (e.g. StackOverflow), the bias towards staleness will amplify given the large body of stale information it has ingested and amalgamated.