Signals vs Virtual DOM: Fine-Grained Reactivity

Q: What exactly is a signal and how does it differ from useState?

A signal is a value that keeps track of who reads it, which is the whole difference. When you read a signal inside a tracked scope — an effect or a computed — the runtime records that this computation depends on that value. When the value changes, the runtime already knows the exact set of computations to re-run and the exact DOM nodes to update. Nothing is rebuilt and nothing is compared. With useState, the framework knows a value changed but not who depends on it, so its only safe strategy is to re-run the component function, build a new element tree, and diff that tree against the previous one to find what actually changed. That diffing work is the price of missing dependency information, and it is proportional to the size of the subtree rather than to the number of things that genuinely care about the change. The practical consequences show up in three places. Updates are proportional to actual subscribers rather than to component tree size. Manual optimisation largely disappears, because memo, useMemo, useCallback and dependency arrays exist to reconstruct by hand the dependency information a signal records automatically. And a whole bug class goes with it — stale closures capturing old values, missing dependency entries, effects that fire more or less often than intended. What replaces them is a different, smaller bug class: reading a signal outside a tracked scope, which returns a value that never updates. Naming differs across frameworks but the primitive is the same: Angular signal, Vue ref, Svelte 5 $state, Solid createSignal, Preact signal. The TC39 proposal aims to put one implementation in the language so frameworks stop shipping their own.

Q: Should we migrate our React application to a signals-based framework?

Almost certainly not as a migration project, and this is the question where the online discussion is least useful. The honest position: signals are the better default for new work, and rewriting a working application to adopt them is spending a product roadmap to buy a maintainability improvement you can get incrementally. React ships an enormous amount of production software, its model works, and the compiler that automates memoisation addresses most of the ergonomic complaint that drove people toward signals in the first place. Consider three questions before anything else. Is your actual bottleneck rendering? In most applications we review it is not — it is data fetching, bundle size, an N+1 at the API, or unoptimised images, and none of those are improved by changing the reactivity model. Can you hire for the alternative? The React ecosystem and hiring pool are far larger, and that is a real engineering cost that does not appear in a benchmark. Do you have a specific problem signals solve? A dashboard with thousands of independently updating cells is a genuine case. A CRUD application is not. Where adoption makes sense: new applications, where signals are a straightforward better default; new isolated features or islands inside an existing app, where the two models coexist without ceremony; and genuinely update-heavy surfaces such as real-time dashboards, collaborative editors and data grids. If you do adopt incrementally, the important discipline is not to carry VDOM-era habits across — manual memo boundaries in a fine-grained system add indirection and cost while preventing nothing, because the dependency graph already does that job.

Q: How does automatic dependency tracking actually work?

Through a deceptively simple mechanism: the runtime maintains a pointer to the currently executing computation, and any signal read while that pointer is set registers itself as a dependency. When an effect or computed begins evaluating, the runtime sets the pointer to that computation. Every signal read during evaluation checks the pointer, and if one is set, adds the computation to its subscriber list and itself to the computation dependency set. When evaluation finishes, the pointer is cleared. The result is an accurate dependency graph built purely from what the code actually read, with no declaration required from the developer. Two consequences follow directly and explain most real-world behaviour. Dependencies are dynamic: if a computed reads signal A on one run and, because of a branch, signal B on the next, the graph updates accordingly — which is more precise than a static dependency array can be, since the array must list everything any branch might touch. And reading a signal outside a tracked scope silently returns a plain non-reactive value. There is no pointer set, so no dependency is recorded, so nothing ever updates. This is the single most common signals bug, it looks exactly like the framework being broken, and the first thing to check is always whether the read happened inside a reactive scope. Real implementations add machinery for correctness. Naive propagation can briefly expose an inconsistent intermediate state when one update reaches a node through two paths of different lengths, so implementations topologically sort the graph and batch updates so observers only ever see a consistent snapshot — usually called glitch-free propagation. Computeds also evaluate lazily and cache, recomputing only when read and only if a dependency actually changed, which is why long derivation chains cost nothing until someone observes the end of one.

Q: Do signals make applications measurably faster?

Sometimes, and usually less than the discussion implies — the stronger argument for signals is maintainability rather than speed. Where the performance difference is real: applications with many independently updating values, such as real-time dashboards, trading interfaces, collaborative editors and large data grids. Updating three cells in a table of ten thousand touches three DOM nodes under fine-grained reactivity, whereas a VDOM approach without careful memoisation re-renders and diffs a much larger subtree. That is a genuine architectural advantage, not a micro-optimisation. Where it mostly is not real: typical CRUD applications, content sites, forms, and anything whose interaction rate is human-paced. A well-memoised React application and a signals application will both feel instant, and the difference will be a few milliseconds that no user perceives. Choosing a framework on a 5ms benchmark delta while your largest contentful paint is dominated by an unoptimised hero image is optimising the wrong layer. There is also a bundle consideration that cuts in favour of signals: no reconciler needs to ship, and more work moves to the compiler, so runtimes tend to be smaller. That matters most on slow networks and low-end devices, which is a real user population rather than a benchmark artefact. The argument I would actually make to a team is about the code rather than the clock. Removing memo boundaries, dependency arrays and stale-closure bugs makes a codebase meaningfully easier to change safely, and easier-to-change code ships better performance over time because optimisation stops being risky. That is a durable benefit; a benchmark win on a synthetic test is not.

Q: What are the most common mistakes when adopting signals?

Five recur, and the first accounts for most of the confusion. Reading a signal outside a tracked scope. The read returns a value that never updates and the component appears frozen, which reads as a framework fault rather than a usage error. There is no pointer set during the read, so no dependency is recorded. Always check the reactive scope first. Carrying VDOM memoisation across. Teams migrate and keep their memo wrappers, useMemo calls and stable-callback patterns. In a fine-grained system these add indirection and allocation while preventing nothing, because the dependency graph already performs that job. Delete them deliberately as part of adoption rather than leaving them as dead weight. Putting everything in global signals. Signals make ambient reactive state easy to create, and easy is not the same as wise. Global reactive state is as hard to reason about as any other global, and it defeats the scoping that makes components composable and testable. Scope state to the narrowest place that needs it. Effects that write signals they also read. This creates a cycle that either loops or is silently broken by the runtime, and both outcomes are hard to debug. If a value derives from other values, express it as a computed. Effects are for side effects that leave the graph — DOM writes, storage, network — not for propagating state back into it. Forgetting cleanup. Subscriptions, timers, listeners and observers created inside effects leak on disposal exactly as they always have. The reactive model tracks values, not resources. One more worth noting: assuming signals solve state management. They give you a primitive, not an architecture. Cache invalidation, request deduplication, optimistic updates, offline behaviour and server-state synchronisation are unchanged, and teams that delete their state library on adoption frequently rediscover why it existed.

Q: What does the TC39 signals proposal mean for framework choice?

If it advances, it means the reactivity primitive stops being a framework differentiator and becomes shared infrastructure, which is good for interoperability and largely neutral for the choice you make today. The proposal aims to put a signal implementation into JavaScript itself, so frameworks build their ergonomics on a common core rather than each shipping an incompatible one. The practical benefits would be real. Interoperability: a state library or a component written against standard signals could work across frameworks, which is close to impossible today because each implementation has its own tracking mechanics. Smaller bundles: frameworks stop shipping their own reactivity runtime. Better tooling: browser devtools could understand the dependency graph natively rather than each framework building bespoke inspection. And potentially better performance, since an engine implementation can optimise in ways a library cannot. The caveats matter as much as the benefits. TC39 proposals move through stages over years and can stall or change substantially; nothing here is a reason to defer a decision. Frameworks will keep their own APIs on top regardless, so the developer-facing surface — Angular signal, Vue ref, Svelte runes — will not converge even if the underlying primitive does. And existing implementations will not disappear; they will gradually delegate to the standard where it makes sense. For a team choosing a framework in 2026 the proposal changes very little in the near term. Choose on ecosystem, hiring, the server-rendering story, and what your team already knows. Treat the standardisation effort as confirmation that fine-grained reactivity is the settled direction rather than a passing preference — which is a useful signal for long-horizon planning, and not an argument for any particular framework.

Q: How do signals interact with server-side rendering and server components?

They are largely orthogonal, and recognising that resolves a lot of confused debate. Signals are a client-side reactivity model: they describe how state changes propagate to the DOM once the page is interactive. Server rendering, streaming, server components and resumability describe how markup and data get to the browser in the first place. A signals runtime composes with any of those approaches, and choosing signals does not commit you to a client-heavy architecture. Concretely, every major signals framework has a server story. Angular, Vue, Svelte and Solid all render on the server and hydrate on the client; Qwik uses resumability to avoid the hydration step entirely; and island architectures let you ship signals only for the genuinely interactive parts of an otherwise static page. What is less settled than in the mature React ecosystem is the boundary between server data and client reactivity — the patterns for streaming server data into signals, for handling suspense and loading states, and for reconciling optimistic client updates with server truth are still converging across frameworks. That is a real consideration if you are building something data-heavy today, and it is improving quickly rather than being a permanent limitation. The design attention worth spending is on the boundary itself: what renders on the server, what data crosses, how it is cached, and what becomes reactive on the client. That decision determines far more about your application performance and complexity than the choice of reactivity primitive. Teams frequently invert this, spending weeks on the framework question and minutes on the data boundary, and then find their performance problem was never in the rendering layer at all.

Q: Are there cases where signals are the wrong tool?

Yes, and they are worth naming because trying to force them produces genuinely bad architecture. Continuous animation and render loops. Anything driving frames at 60fps — canvas work, WebGL or WebGPU scenes, physics simulation, game loops — should own its own requestAnimationFrame loop and read state directly rather than being pushed by signal updates. The reactive graph is designed for discrete state changes; using it as an animation driver adds overhead and gives you less control over frame timing. Very high-frequency event streams. Raw pointer movement, scroll position, or a socket delivering many messages per second should be throttled, debounced or batched before entering the graph. Pushing every event through reactivity moves the performance problem one layer down rather than solving it. Server state as a substitute for a data layer. Signals hold client state well. They do not give you caching, request deduplication, retry, stale-while-revalidate, optimistic updates or offline reconciliation, and building those on raw signals means reimplementing a query library badly. Use a data layer and let signals hold what it returns. Purely static content. A marketing page or documentation site with no interactive state gains nothing from a reactivity system, and the right answer there is usually less JavaScript rather than better JavaScript. Complex derived state with heavy computation. Computeds are lazy and cached, which helps, but a genuinely expensive derivation still blocks the main thread when it runs. That belongs in a worker, with the result fed back into a signal. The general test: signals excel at discrete state changes propagating to specific outputs. When the workload is continuous, extremely high-frequency, or genuinely compute-bound, it belongs outside the graph.