Signals Are Changing How We Think About Reactivity — and React Is Paying Attention
Signals aren't new, but their moment in the frontend mainstream is arriving. Understanding why they're compelling — and what they'd cost — is becoming a relevant skill.
If you've been paying attention to the JavaScript framework space over the last two years, you've noticed that signals keep coming up. Solid.js built its identity around them. Preact added them as a library. Angular rewrote its reactivity model around them. Svelte 5 rethought its entire compiler output to implement them. And somewhere in the background, the React team has been watching, openly exploring, and occasionally hinting that the model they've used since 2013 might not be the final word on reactivity.
This is worth paying attention to — not because signals are new (they've existed in various forms since Knockout.js in 2010) but because their moment of mainstream relevance is arriving, and understanding what they offer and what they cost is becoming a practically useful thing to know.
React's component re-render model was a brilliant simplification. Signals are asking whether that simplification is worth the performance ceiling it creates.
The core difference
React's model is conceptually elegant: when state changes, the component (and potentially its subtree) re-renders. You describe what the UI should look like given the current state, and React reconciles the difference. The mental model is simple — a function of state — and it made React much easier to reason about than the imperative, mutation-based alternatives that came before it.
The cost of this model is re-renders. When state updates, React has to figure out what changed by running your components again and comparing the output. For most UIs, this is fast enough that the cost is invisible. For UIs with many components, frequent updates, or complex trees, the reconciliation overhead becomes a real bottleneck. memo(), useMemo(), and useCallback() exist to manually patch holes in the model.
Signals take a different approach: instead of re-running components when state changes, only the specific DOM nodes or computations that depend on a signal update. There's no reconciliation pass, no component re-render, no virtual DOM diffing. The update propagates directly from the signal to whatever depends on it.
What this means in practice
In benchmarks, signal-based frameworks consistently outperform React on update-heavy scenarios — large lists, real-time data, high-frequency interactions. The gap is meaningful. Solid.js, which is probably the most performance-focused signal-based framework, produces updates that are measurably faster for the kinds of UIs where React's overhead becomes visible.
That said, benchmarks are controlled environments. In most product codebases — forms, dashboards, content-heavy pages — React's performance is fine, and the signal-based frameworks don't offer a practical advantage that justifies switching. The interesting cases are the ones at the edges: data visualization tools, collaborative editing, real-time feeds, game interfaces. For those, the difference between "re-render the component" and "update this specific node" is the difference between smooth and janky.
- Solid.js — built entirely on signals; fastest mainstream framework in most benchmarks
- Preact Signals — optional library that works with existing Preact and React code
- Angular 17+ — signals are now the recommended reactivity primitive
- Svelte 5 — runes system is a signal-based rewrite of Svelte's reactivity
- Vue 3 —
ref()andcomputed()are signal-like primitives
What React is actually doing
The React Forget compiler (now React Compiler, shipping in React 19) is the team's answer to the manual memoization problem. Rather than requiring developers to manually annotate dependencies with useMemo(), the compiler automatically inserts memoization where it's beneficial. This gets React much of the practical performance benefit of signals without changing the component model that millions of codebases depend on.
Whether that's enough to close the gap with signal-based frameworks at the high-performance end is genuinely unclear. The React team has explicitly said they're exploring signal-like primitives, but they've also been clear that backward compatibility and ecosystem stability are first-order concerns. A signal-based React would be a different product from the one most people are using.
The practical takeaway
If you're starting a new project today and performance under high update frequency is a core requirement, it's worth evaluating Solid.js seriously. The ecosystem is smaller but the primitives are excellent and the mental model is coherent. If you're maintaining an existing React application, the React Compiler and careful component architecture will handle the vast majority of performance problems without a framework switch.
But the larger shift is worth following regardless of what you're building on. The signal model is proving influential enough that it's reshaping how the entire frontend space thinks about reactivity. Understanding it at a conceptual level — what problem it solves and why the tradeoffs are different — will be useful context as the frameworks you use continue to evolve around it.