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’ve 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 the hot takes, and I’m not moving, at least not yet.

What signals actually fix is real, and I don’t want to pretend otherwise. The core pitch is genuinely good: instead of a component re-rendering and React figuring out what actually changed via the 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 the difference on a page with a lot of independently-updating widgets was noticeable — no memo, no useCallback wrapping every prop, no debugging why a child re-rendered when its actual props didn’t change. If I were starting a project from zero with performance as the top constraint, that’s a real point in Solid’s favor, not a hypothetical one.

What the hype consistently understates: how much of “React needs useMemo everywhere” is actually 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, and 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 a React problem that’s architecturally unfixable. Signals make that class of mistake harder to make by default, which is a legitimate ergonomic win — but it’s not the same as React being unable to solve it.

The part that actually keeps me on React isn’t performance, it’s the hiring and ecosystem math. 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, and one where I’m not 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, and yes, more legacy-encumbered than Solid’s — but that messiness comes with ten years of “someone already solved this exact problem” that I actually 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.” That’s not a knock on Solid’s technical merits. It’s a statement about what “boring and proven” is actually worth on a client project I might hand off in a year.

Where I think the signals crowd is right that something will eventually give: React’s own team clearly knows this pressure exists. The compiler work React’s been doing — automatically memoizing what a human used to have to memoize by hand — is a tacit admission that the manual useMemo/useCallback dance was never supposed to be a permanent feature, it was a stopgap. If that compiler work matures to the point where most of the manual re-render management just goes away without switching architectures entirely, a lot of the signals-vs-React framing stops mattering, because the actual complaint — that React makes you think about re-renders constantly — gets solved without requiring anyone to rewrite anything. I’m watching that more closely than I’m watching Solid’s growth, because it’s the more realistic path for what I actually maintain.

What would actually change my mind: a client project with genuinely demanding real-time UI requirements — something with dozens of independently updating widgets, not the CRUD-heavy internal tools that make up most of my work — where the re-render overhead is a measured, real problem rather than a theoretical one. I haven’t hit that yet. Most of what I build is forms, tables, and 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 that I’ll need it eventually, is exactly the kind of 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.