Strangely, after having read the article, now I am wondering why the React team can't just borrow some of these optimizations. It would take a massive overhaul, but it's not like React has ever stood still, it's constantly evolving and changing. I wouldn't be surprised if the under the hood stuff continues to change in a huge way, just like it did when React Fiber was completed.

At the end of the day, I've never spoken to a developer who was using React because it was fast, but because it was easy to use and understand.

React’s changes over time have always been broadly compatible, and the same under the hood, just presented and manipulated a different way at the surface. Migrating to anything like Svelte would be a radical and extremely incompatible change on multiple fronts. It’s never, ever going to happen; the closest you’ll get will be another layer on top of React that embeds something like Svelte—such as https://github.com/Rich-Harris/react-svelte.

Svelte’s approach requires detailed knowledge of the structure of state, and requires compilation: components’ <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics, and some places where JavaScript is too flexible to be tractable get replaced with special template syntax (like {#each} instead of for-loops or Array.prototype.map). Svelte cannot be implemented as a JavaScript library (I disqualify eval()). Svelte is also deliberately severely limited in what it can express in various places, whereas React gives you the full power of JavaScript (for better and for worse).

You could perhaps implement an optimising compiler for a small subset of React components that avoid problematic patterns and are written in TypeScript with proper specifications of the types of state and props; but if you considered it unacceptable for this compiler to change the component’s semantics, I think you’d be surprised at how little serious React code in the wild could actually be supported. Even simple loops might be out of reach. The Svelte approach can’t be a progressive enhancement, it’s an all-or-nothing (at the component level).

> <script> blocks are not written in JavaScript, but rather a language with the same general syntax but different semantics

One could argue that React's hooks are the same: they look like JS but change JS semantics.

However, your point is still valid.

Nah, React hooks are still JavaScript—they’re library functionality, executed directly as JavaScript.

I was quite involved in the project around 2017-2018, and this is just what I feel, but I think the API is pretty much hardened at this point. Context was a disaster. Hooks are useful but more difficult to reason about compared to classes. They have said straight out that JIT optimizations don't work well when the main pattern was to heavily manipulate a singular state object, and that was a culture that I think they failed to change with Hooks.

If Facebook comes up with something else, I think it will be something new. Maybe that is Reason, or something that abuses WASM/Rust in the core architecture. Who knows. The project has a lot of tech debt, and the ecosystem has changed quite a bit as well.

Context and hooks both feel very much like "I'm being paid to work on this but it's basically done... so... guess I'll find something to do" additions. The latter especially.

Hooks are a big shift towards a more fine grained reactive programming in terms of API. However even vdom vs reactivity systems is not an obvious choice, since they have their tradeoffs. The same conflict is much more visible in vue. Thankfully, there are a lot of alternatives that explore this problem space