TC39's Signals Proposal: Why It Matters Before You Pick Another State Library

Reactivity (the pattern where a value change automatically propagates to everything that depends on it) has quietly become the shared foundation under most modern JavaScript frameworks. Vue has it. Solid has it. Preact has it as an add-on. Angular rebuilt its core around it. React has arrived at something adjacent through hooks and re-renders. TC39 now wants to put the underlying primitive into the language itself.

That’s worth understanding even though it won’t affect your code for years. Here’s what it actually proposes, and why it doesn’t change your state-management decision this quarter.

What a signal actually is

Strip away the framework-specific APIs and a signal is a small, specific thing: a container holding a value, which automatically tracks who reads it, and automatically notifies those readers when the value changes.

// Conceptual, framework-agnostic shape of what the proposal targets
const count = new Signal.State(0);
const doubled = new Signal.Computed(() => count.get() * 2);

console.log(doubled.get()); // 0
count.set(5);
console.log(doubled.get()); // 10, recomputed automatically

No manual subscription. No explicit “re-render this component” call. The dependency graph builds itself as code reads signal values, and updates propagate through that graph when a value changes. This is the core idea every reactive framework already implements in some form; the proposal’s job is to standardize the primitive, not invent a new pattern.

Why frameworks converged on this independently

This didn’t come from one framework’s design meeting. It shows up everywhere because it solves the same problem every UI framework has: knowing precisely what needs to update when data changes, without re-checking everything.

Framework	Reactivity approach
Vue	Proxy-based reactive objects, tracked dependencies
SolidJS	Fine-grained signals, no virtual DOM
Angular (16+)	Native signals API, replacing zone-based change detection
Preact	Signals as an official add-on package
React	Hooks plus re-render diffing (a different model, not signal-based)

Vue and Solid arrived at nearly identical mental models independently. Angular went further and rebuilt its whole change-detection system around signals, moving away from zone.js. That’s not a coincidence, and it’s the strongest evidence that TC39 is standardizing something real rather than picking a side in a framework debate. Our look at Angular’s signals-driven comeback covers what that migration looked like in practice for one framework; TC39’s proposal is the industry-wide version of the same bet.

React is the interesting holdout. Its model (state changes trigger re-renders, which get diffed against a virtual DOM) solves a related problem differently, and it’s not a natural fit for a drop-in signals primitive. Don’t expect React to switch to native signals wholesale even once they land in browsers; expect, at most, interop layers and optional APIs built on top.

What TC39 is and isn’t standardizing

It’s worth being precise here, because “signals are coming to JavaScript” oversells what’s actually proposed. TC39 is standardizing the primitive: Signal.State and Signal.Computed, roughly, plus the semantics for how dependency tracking and change propagation work at the language level.

It is not standardizing:

• A component model or rendering system
• A specific state management pattern (global store vs. local component state)
• Framework-level concerns like effects, lifecycle hooks, or async state

That distinction matters. Native signals would give framework authors a shared, engine-optimized building block to construct reactivity on top of. They would not obsolete the frameworks themselves, any more than the array methods JavaScript standardized obsoleted lodash entirely; they’d just mean less duplicated, less optimizable JavaScript doing the same fundamental job across every framework’s bundle.

The realistic timeline

Per the proposal’s own contributors, native signals being available across browsers going back a few versions is at least 2-3 years out at an absolute minimum, contingent on smooth progress through TC39’s stage process (which has stalled or reworked plenty of proposals before). All contributors have signed the required IP agreements and the plan is to present formally to committee, but “presented to committee” and “shipped in every evergreen browser” are years apart in practice.

For comparison, that’s a longer horizon than the release cycle of any framework covered on this blog. Nothing about choosing a state management approach today should be delayed waiting on this.

What to actually do with this information

If you’re picking a state management library for a project starting now, pick based on today’s tradeoffs: bundle size, your team’s familiarity, the specific problem (local component state versus global app state versus server state), and how well it’s actually maintained. Our comparison of Zustand and Jotai for React state management is still the right reference point for that decision, and nothing here changes its conclusions.

Where TC39’s Signals proposal is genuinely useful is as a directional signal for architecture decisions with a longer horizon: if you’re evaluating a new framework, or deciding how deeply to couple your application logic to a specific reactivity implementation, it’s worth knowing that the ecosystem is converging on this pattern at the language level. That convergence is a reasonable tiebreaker when two frameworks are otherwise close, not a reason to hold off shipping anything today.

Reactivity is becoming a language feature, eventually. Build your app with the tools that fit it now, and let the standard catch up.