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.

but what about signals

React should have adopted signals before going nuts on a compiler or RSCs IMO. My 5 year prediction is a solid one… 😜

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

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.

useState and useMemo are basically very explicit very poorly integrated signals.

Cosigned.

Love this. And true. I forget about the vdom limitations too easily. My last phrase still stands.

We can have a best of both worlds though the DX of renders for i.e. conditional jsx and optimised updates for text and attribute nodes. We do that in preact-signals Briefly wrote about the difference to hooks jovidecroock.com/blog/signals

We're actually using our own signals implementation to power various TanStack projects going forward 😄

Any insight into why you'd roll your own at this point? Preact's is agnostic, fast, small and sel contained...

Admittedly the things I was looking for was: - Small (Preact's got) - No auto tracking (explicitness in library code) - Any side effects being "mountable" and unmountable (namely for React support) - Ability to diff new vs previous values so we can keep referencial stability between computations

Yup: tanstack.com/store