This is Learning

I like the article, but it gets some things subtly wrong.

> To grossly oversimplify things: React assumes that your entire virtual DOM tree needs to be rebuilt from scratch, and the only way to prevent these updates is to implement useMemo

Not quite, on a state update, it rebuilds the component that was updated and all of its children. Not the entire virtual DOM; old versions of Angular did this, but it was wasteful.

useMemo doesn't prevent that, but React.memo can (useMemo has a different role; it lets you choose when to recompute or recreate a normal JavaScript object. But on its own it won't stop rerendering of child components!) [0]

This invalidates some of their assumptions. The reason why React isn't "push-only" isn't because it does that, it's because it sometimes buffers updates instead of always pushing them immediately. In fact, other frameworks like Svelte also aren't "push-only" and hence not strictly reactive! (Funnily enough, OP uses an article as a source that explains this correctly [1], but it seems they took the wrong lesson from it).

The reason why signals are so cool is because the framework knows for any given state change which exact attributes in the DOM need to be re-rendered, even more specifically than "the element and all its children". But this neither implies reactivity nor the other way around. The two concepts are orthogonal.

Anyways, kudos to the author for diving into this so deeply!

[0] useMemo is useful in combination with React.memo…

Another way of stating it is that Svelte doesn't attempt to plug any of the leaky abstractions that already existed in JavaScript.

JavaScript is riddled with huge footguns that aren't even exotic use cases, and if you remove or paper over them, then it's not JavaScript any more.

While React's biggest most obvious leaky abstraction is that React isn't actually reactive.

Neither is Svelte, but at least Svelte doesn't have the audacity to falsly CLAIM it's reactive in ITS OWN NAME, like React does!

I do give Svelte credit for being quite self-referentially svelte, though! And that's something great that React definitely isn't.

How React isn't reactive, and why you shouldn't care

https://dev.to/this-is-learning/how-react-isn-t-reactive-and-why-you-shouldn-t-care-152m

>[...] Is React not reactive?

>Well, let's see about that. React components are driven off state, and setState calls are sort of like data events. And React's Hooks and JSX are basically declarative. So what's the issue here?

>Well actually very little. There is only one key difference, React decouples the data events from component updates. In the middle, it has a scheduler. You may setState a dozen times but React takes notice of which components have been scheduled to update and doesn't bother doing so until it is ready.

>But all of this is a type of buffering. Not only is the queue filled by the state update event, but the scheduling of processing that queue is as well. React isn't sitting there with…

> At least it shows that the technology is both scalable and battle-tested.

So are all other technologies used on the web sites. It still doesn't make it good.

You keep pretending that if something is used somewhere means it's good.

> It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later.

So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components.

> Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM.

But yeah. It's here to stay.

As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]

There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web…

At some point, the creator of SolidJS, Ryan Carniato did a stint helping developing Marko.js, a fine-grained reactive / compiled / a bit HTMX-like system, and blogged about that. It's a framework that originated from eBay. I'm now quite interested about the next version of Marko.js, Marko.js 6, and I'm gonna try it for my new project.

I'm interested in fine-graned reactivity so Svelte and SolidJS have been on my radar, but the HTMX-style approach appeals to me.

Here's something to munch on:

https://dev.to/ryansolid/marko-compiling-fine-grained-reactivity-4lk4

https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d

https://www.youtube.com/watch?v=Z1dd09rxny4

Maybe SignalDB?: https://signaldb.js.org/core-concepts/#signals-and-reactivity

I swear I read that MeteorJS and/or MongoDB implemented signals for the DB layer. While searching for the source, I found SignalDB.

---

edit: Found the source:

https://dev.to/this-is-learning/the-evolution-of-signals-in-javascript-8ob#comment-2561f

> ...Meteor Tracker is a good prior art on signals and effects history in JS (although not using the same terminology). The really magical thing about Meteor is that their "signals" and "effects" are database connected: you use variables in your frontend template, and those values can come directly from a backend DB...

Per some tests as of last year[0], Marko[1] is much more performant than Svelte, which matters a lot for UX and for page rankings (especially in case of more complex sites).

I’d expect Qwik to be faster than any of the above, but it seems not quite production-ready enough.

[0] https://dev.to/this-is-learning/marko-for-sites-solid-for-apps-2c7d

[1] In the Reddit the author mentions that, despite focusing on Solid+Astro in the article, Marko is actually still more performant than those: https://www.reddit.com/r/javascript/comments/ubs6i9/marko_for_sites_solid_for_apps/