Post

tried writing this blog 3 times but it’s really boring, so here’s the short version: React won. Every mainstream f/w now implements its ideas, and developed their own ecosystems. The ones that didn’t, lost and died. This implies there’s no _strong_ reason to not pick one of the other winners.

Without a compiler, and with the virtualized DOM paradigm, I don’t really know that react is in a great position to benefit from signals. Frameworks that use compilers and ā€œtemplatedā€œ DOM (including JSX usage) will always have an advantage using any reactive primitive for targeted updates

and then React would basically become Solid.js where signals update discreet pieces of the DOM (rather than virtual trees and diffing of those trees to finally figure out what changed, signals already tell you exactly what changed so vdom diffing is superflous, redundant, and wasteful with Signals).

Put differently, if we react has to build an object tree, and then diff it against another object tree in order to know what to update, then targeted updates aren’t really on the table. And reactive types like signals really don’t have any direct advantage for react.

I'm no VDOM fan, but I don't think this is necessarily true. Targeted updates can just happen outside of the main update path. This is what we do in Lit. For a React component that only has targeted updates it turns the function into a setup like Solid, but without the nice syntax for computeds.

I do agree, but if they slacken the vdom paradigm a bit and allow signals to directly alter the backing DOM nodes, you can get much of the perf benefit whilst keeping most vdom semantics/control flow. Not that I think they'd go for it except maybe w/ the compiler, given past comments.

I still genuinely don't know what "React adopt signals" would _mean_ at a technical level. Per other comments in this thread, React works at the component level. What would a hypothetical native-to-React signals integration do differently?

It would have to have been something new. Breaking likely. Signals would allow: - finer grained updates than ā€œcomponentā€ e.g. jsx fragments - state/data flow that isn’t tied to component hierarchy and doesn’t need to rerender (or subscribe to a store to rerender) itself and its children

Wasn’t the whole premise of react that re-run all the time cause it’s generally fast. Wouldn’t this break that mental model? Honestly I like the way react works, almost all the other frameworks have the same signal based reactive model. We need competing models.

for change detection. - useMemo/useCallback would actually only get used for heavy computations instead of referential stability Just spitballing here. But look at Preact signals for more ideas.

Still feel you can get very close with React + Jotai. Jotai has nearly the same API as Signals. It’s also underrated vs Zustand IMO. Atomic state is so beautiful and elegant once you master it.

Indeed. They would have discovered that signals optimize data flow across paths a compiler can never know about, including across files/dependencies/bundles. They make the entire compiler redundant.