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… 😜

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.

It was fast compared to existing models back 8 years ago. But now it’s easy to get into trouble quickly. Fine grained reactivity is the next step, just like functional memoization was from digest cycles and dirty checking.

Fine-grained reactivity *in the platform*, I'd say. Signals (by other names) have been around since long before React. They didn't have the juice on their own back then. We'll see if they do now.

Where's a good writeup on the new implementation?

@ryansolid.bsky.social @devagr.bsky.social

this might help bsky.app/profile/deva...