JavaScript Signals Are Coming: What TC39’s Reactivity Proposal Means for Your Development Team

For over a decade, every major JavaScript framework has invented its own flavour of reactivity. Angular has Signals. Vue has ref() and computed(). Solid pioneered fine-grained reactivity. Svelte compiles reactivity away entirely. Preact shipped its own Signals library. If you have ever migrated a front-end codebase from one framework to another, you know the pain — your state management logic is locked inside a proprietary reactive system, and none of it transfers.

That is about to change. The TC39 Signals proposal, now at Stage 1, aims to bring a standard reactive primitive directly into the JavaScript language. Backed by authors and maintainers from Angular, Vue, Solid, Preact, Ember, Qwik, MobX, and more, this is the broadest framework-author collaboration in JavaScript history — and it has serious implications for how your team builds software.

TL;DR

• TC39’s Signals proposal adds a native reactive primitive to JavaScript, backed by maintainers from Angular, Vue, Solid, Preact, Ember, Qwik, and MobX.
• Standard Signals decouple state management logic from frameworks — write it once, render it with any framework.
• Automatic dependency tracking replaces error-prone manual subscriptions, reducing boilerplate and eliminating an entire class of bugs.
• The proposal is at Stage 1, meaning the API is not finalised, but the direction is clear and polyfills already exist.
• Development teams should start learning the Signals mental model now, as it will likely shape JavaScript for the next decade.

What Are Signals, Exactly?

A signal is a reactive container for a value. When the value changes, anything that depends on it updates automatically. There are two core concepts:

• State signals — writable containers that hold a value. Think of them as reactive variables.
• Computed signals — derived values that automatically recalculate when their dependencies change. Think of them as reactive formulas in a spreadsheet.

The key innovation is automatic dependency tracking. When a computed signal runs, the runtime records which state signals it reads. If any of those dependencies change later, the computed signal knows it needs to recalculate — no manual subscription, no cleanup, no forgetting to unsubscribe.

// Conceptual TC39 Signals API (subject to change)
const counter = new Signal.State(0);
const doubled = new Signal.Computed(() => counter.get() * 2);

console.log(doubled.get()); // 0
counter.set(5);
console.log(doubled.get()); // 10

If this looks familiar, that is the point. Every framework has converged on roughly this pattern. The TC39 proposal standardises the underlying graph so that frameworks can share a common reactive core whilst still differentiating on rendering, templating, and developer experience.

Why This Matters More Than You Think

1. Framework-Agnostic State Logic

Today, if you write a piece of business logic using Vue’s ref() and computed(), it only works inside Vue. With standard Signals, you could write that same logic once and plug it into Angular, Solid, Lit, or any framework that adopts the standard. Your state management becomes portable infrastructure, not framework lock-in.

For agencies like us at REPTILEHAUS, this is particularly significant. We work across multiple frameworks depending on the project and client requirements. A shared reactive primitive means utility libraries, validation logic, and state machines can follow us between stacks without rewriting.

2. The End of the State Management Wars

Redux, MobX, Zustand, Pinia, Jotai, Recoil — the JavaScript ecosystem has produced an extraordinary number of state management libraries, each solving the same fundamental problem in slightly different ways. Standard Signals do not eliminate these libraries overnight, but they do provide a common foundation that many of them can build on. Several library authors are already exploring how their tools could use standard Signals internally.

3. Smaller Bundles, Fewer Dependencies

When reactivity lives in the runtime, frameworks no longer need to ship their own reactive graph implementation. That is kilobytes of JavaScript that disappear from your bundle. For performance-sensitive applications — and our clients’ projects increasingly fall into that category — every kilobyte matters.

4. Better Developer Experience

Manual subscription management is a notorious source of bugs: memory leaks from forgotten unsubscriptions, stale closures, race conditions between async updates. Signals’ automatic tracking model eliminates this entire class of problems. If you have ever debugged a useEffect dependency array in React, you understand the appeal.

The Collaboration Behind the Proposal

What makes this proposal unusual is the breadth of its backing. The champions include Daniel Ehrenberg (Igalia, TC39 delegate), Rob Eisenberg (FAST, Aurelia), and contributors from Angular, Vue, Solid, Preact, Qwik, Svelte, Ember, MobX, RxJS, and more. This is not one framework trying to get its pattern standardised — it is competing frameworks agreeing on shared infrastructure.

The proposal explicitly draws a parallel to the Promises/A+ effort that preceded ES2015 Promises. Different libraries (jQuery Deferred, Bluebird, Q, RSVP) had all converged on similar async patterns, and standardisation unified the ecosystem. The Signals proposal aims to do the same for reactivity.

What the Proposal Does Not Do

It is worth being clear about the boundaries. Standard Signals provide the reactive graph — the data layer. They do not standardise:

• Rendering — how signals connect to the DOM remains framework territory.
• Effects — side-effect scheduling (the equivalent of useEffect or watchEffect) is intentionally left out of the initial proposal.
• Syntax — there is no special language syntax. Signals are a library-level API, similar to how Promise is a constructor rather than a keyword.

This is a deliberate design choice. By keeping the scope focused on the core reactive primitive, the proposal avoids the design-by-committee sprawl that has slowed other TC39 proposals.

Where Things Stand Today

The proposal is at TC39 Stage 1, which means the committee has agreed the problem is worth solving and is exploring solutions. The API is not finalised, and there is no guaranteed timeline for shipping in browsers. Stage 1 proposals can and do change significantly.

That said, the momentum is real. Polyfills already exist, framework authors are actively collaborating on the design, and the core reactive model is well-proven across multiple production frameworks. The question is not whether JavaScript gets standard reactivity, but what the final API looks like.

What Your Team Should Do Now

You do not need to rewrite anything today. But there are practical steps worth taking:

1. Learn the Signals mental model. If your team primarily uses React, the Signals pattern (fine-grained reactivity without a virtual DOM diff) may feel unfamiliar. Experiment with Preact Signals, Solid, or Angular Signals to build intuition.
2. Isolate state logic from rendering. Regardless of which framework you use, structuring your code so that business logic and state management are separate from UI components will pay dividends — whether or not you ever migrate frameworks.
3. Watch the proposal. Follow the tc39/proposal-signals repository on GitHub for updates. Stage 1 to Stage 3 typically takes 1-3 years, but early awareness lets you plan ahead.
4. Evaluate your state management stack. If you are choosing a state management library for a new project, consider whether it aligns with the Signals pattern. Libraries that build on signal-like primitives are more likely to integrate smoothly with the standard once it lands.

The Bigger Picture

JavaScript has a long history of the ecosystem converging on patterns before the language catches up. Modules, Promises, classes, iterators — all followed this arc. Signals are the next iteration of that story, and arguably the most impactful since Promises standardised async programming.

For development teams, the message is straightforward: reactivity is becoming a language-level concern, not a framework-level one. The frameworks that thrive will be those that embrace the standard and differentiate on developer experience, tooling, and rendering performance — not on inventing yet another reactive primitive.

At REPTILEHAUS, we are already structuring our internal libraries and client projects with this transition in mind. If your team is planning a front-end architecture and wants to future-proof your approach, get in touch — we would be happy to help you navigate the shift.

📷 Photo by Peaky Frames on Unsplash