Everyone's Excited About Signals — I'm Not Rewriting My React Stack Yet

If you follow frontend Twitter or read enough JS newsletters, you’ve seen the framing by now: signals won the framework war, and React is the one holdout still pretending re-renders and useMemo are fine. Solid had signals from day one, Svelte’s runes are signals with better ergonomics, Vue’s reactivity system has quietly been signals-shaped for a while, and even Preact ships a signals package now. React, meanwhile, is still doing top-down re-renders reconciled with a virtual DOM, and the pitch from the signals crowd is that this is basically legacy architecture at this point.

I build most of my client-facing internal tools on React + Spring Boot, so this isn’t an abstract debate for me — it’s a real question about whether my default stack is quietly becoming the thing people apologize for using. I spent a chunk of this year actually reading the arguments and poking at Solid and Svelte on small side projects instead of just reacting to hot takes. Conclusion: not moving. At least not yet.

What signals actually fix is real

The core pitch is genuinely good: instead of a component re-rendering and React figuring out what changed via a virtual DOM diff, a signal tracks exactly which pieces of the DOM depend on it and updates only those, without re-running the surrounding component function at all. I built a small dashboard in Solid specifically to feel this, and on a page with a lot of independently-updating widgets, the difference was noticeable — no memo, no useCallback wrapping every prop, no debugging why a child re-rendered when its props didn’t actually change. If I were starting a project from zero with performance as the top constraint, that’s a real point for Solid, not a hypothetical one.

But a lot of “React needs useMemo everywhere” is a skill issue, not an architecture issue

Most of the re-render pain I see in real codebases — including client codebases I’ve inherited — isn’t React’s reconciliation model failing. It’s components that are too broad, state that lives higher in the tree than it needs to, context providers wrapping things that don’t need to be reactive to that context at all. I fixed a genuinely bad re-render cascade in a client project a few months back not by reaching for a signals library, but by splitting one overloaded component into three smaller ones and moving a piece of local state down instead of leaving it at the top.

That’s a React problem you learn to avoid, not one that’s architecturally unfixable. Signals make that class of mistake harder to make by default — a legitimate ergonomic win — but that’s not the same as React being unable to solve it.

What actually keeps me on React: hiring math, not performance

For a solo freelancer picking up client work, the stack I use has to be one a client’s future hire can maintain without me, not one where I’m the only person on the planet who’s touched the specific state library some Solid or Svelte project ended up depending on for anything beyond the basics. React’s ecosystem is bigger, messier, more legacy-encumbered than Solid’s — but that messiness comes with ten years of “someone already solved this exact problem” that I lean on constantly. Every time I’ve reached for something obscure in a client project, there’s a React answer, a maintained library, a Stack Overflow thread from three different eras of the ecosystem. Solid’s answer to the same problem is often “here’s how you’d do it, we just haven’t needed a library for it yet because the community’s smaller.” Not a knock on Solid’s technical merits — it’s a statement about what “boring and proven” is worth on a client project I might hand off in a year.

React’s own team clearly knows this pressure exists, to be fair — the compiler work they’ve been doing (automatically memoizing what a human used to have to memoize by hand) is a tacit admission the manual useMemo/useCallback dance was never meant to be permanent, just a stopgap. If that matures to the point where most manual re-render management just goes away without switching architectures, a lot of the signals-vs-React framing stops mattering, because the actual complaint — React makes you think about re-renders constantly — gets solved without anyone rewriting anything. I’m watching that more closely than I’m watching Solid’s growth.

What would actually change my mind

A client project with genuinely demanding real-time UI requirements — dozens of independently updating widgets, not the CRUD-heavy internal tools that make up most of my work — where re-render overhead is a measured problem, not a theoretical one. Haven’t hit that yet. Most of what I build is forms, tables, dashboards where the bottleneck is never React’s rendering model, it’s the API call underneath it. Rewriting a stack to solve a performance problem I don’t actually have, on the promise I’ll need it eventually, is exactly the premature optimization I try to talk clients out of doing to their own codebases.

I’m not dismissing signals as hype with no substance — the architecture is genuinely elegant and the ergonomics are genuinely better for the specific problem it solves. I just don’t think “genuinely better at one specific thing” is the same as “the thing everyone should rewrite their stack around,” and for the kind of work that actually pays my bills, the boring stack with the bigger ecosystem is still the better bet.