Signals is a simple idea with massive power. In one fell swoop, Signals provides reactivity while keeping state simple, even in large applications. That’s why the Signals pattern has been adopted for inclusion in Solid, Svelte, and Angular.

This article introduces Signals and demonstrates its fresh approach to state management, bringing new life to the JavaScript front end.

Introducing the Signals pattern

The Signals pattern was first introduced in JavaScript’s Knockout framework. The basic idea is that a value alerts the rest of the application when it changes. Instead of a component checking its data every time it renders (as in React‘s pull model), a signal “pushes” the update to exactly where it is needed.

This is a pure expression of reactivity, sometimes called “fine-grained” reactivity. It is almost magical how individual signals can update the output of a value without requiring any intervention from the developer.

The “magic” is really just an application of functional programming, but it has big benefits for an application architecture. The Signals pattern eliminates the need for complex rendering checks in the framework engine. Even more importantly, it can simplify state management by providing a universal mechanism that can be used anywhere, even across components, eliminating the need for centralized stores.

Before Signals: The virtual DOM

To understand why signals are such a breath of fresh air, we can start by looking at the dominant model of the last decade: The Virtual DOM (VDOM), popularized by React.

The VDOM is an abstract DOM that holds a version in memory. When application state changes, the framework re-renders the component tree in memory, compares it to the previous version (a process called diffing), then updates the actual DOM with the differences.

While this makes UI development declarative and predictable, it introduces a cost. The framework does significant work just to determine what hasn’t changed. This is compounded by data-heavy components like lists and trees. And, as applications grow larger, this diffing overhead adds up. Developers then resort to complex optimization techniques (like memoization) in an effort to keep the engine from overworking.

Fine-grained reactivity

State management via VDOM implies repeatedly walking a tree data structure in memory. Signals side-steps this entirely. By using a dependency graph, Signals changes the unit of reactivity. In a VDOM world, the unit is the component, whereas with Signals, the unit is the value itself.

Signals is essentially an observer pattern where the observers are automatically enrolled. When a view template reads an individual signal, it automatically subscribes to it. This creates a simple, direct link between the data and the specific text node or attribute that displays it. When the signal changes, it notifies only those exact subscribers.

This is a point-to-point update. The framework doesn’t need to walk a component tree or determine what changed. This shifts the performance characteristic from O(n) (where n is tree size) to O(1) (immediate, direct update).

Hands-on with Signals

The best way to understand the benefits of Signals is to see the pattern in action. When developing application components, the difference between using Signals and a more traditional VDOM approach is, at first, almost invisible. Here’s React handling a simple state instance:

function Counter() {
  const [count, setCount] = useState(0);
  const double = count * 2;

  return (
     setCount(count + 1)}>
      {count} doubled is {double}
    
  );
}

Now consider the same idea in Svelte using individual signals with the Runes syntax:

 count += 1}>
  {count} doubled is {double}

In both cases, you have a reactive value (count) and a value that is dependent on it (double). They both do the same thing. To see the difference, you can add a console log to them. Here’s the log with React:

export default function Counter() {
  const [count, setCount] = useState(0);
  const double = count * 2;

  console.log("Re-evaluating the world...");

  return (
     setCount(count + 1)}>
      Count is {count}, double is {double}
    
  );
}

Every time the component mounts, or updates, the console will output this line of logging. But now look at the same log from Svelte:

 count += 1}>
  Count is {count}, double is {double}

In this case, the console logging happens only once, when the component mounts.

At first, this seems impossible. But the trick is, the signal just directly connects the value to its output, with no need to invoke the surrounding JavaScript that created it. The component does not need to be re-evaluated. The signal is a portable unit of reactivity.

How Signals eliminates dependent values

Another important result of using signals is how we manage side-effects. In React, we have to declare the dependent values. These are the parameters we pass to useEffect. This is a common area of complaint in terms of developer experience (DX) because it is an additional relationship to manage. Over time, this can lead to mistakes (like forgetting to add a value) and may otherwise impact performance. As an example, consider what happens when there are many values:

useEffect(() => {
  console.log(`The count is now ${count}`);
}, [count]);

Passing the same job with signals eliminates the dependent values:

effect(() => {
  console.log(`The count is now ${count()}`);
});

In this case, we’ve used Angular syntax, but it’s similar across other frameworks that use signals. Here’s the same example with Solid:

createEffect(() => {
  console.log(count());
});

The end of ‘prop drilling’

Using the Signals pattern for state management also impacts application design. We can see it most readily in the way we have to pass properties down the component tree, from parent to child, when we need to share state:

// In React, sharing state can mean passing it down...
function Parent() {
  const [count, setCount] = useState(0);
  return ;
}

function Child({ count }) {
  // ...and down again...
  return ;
}

function GrandChild({ count }) {
  // ...until it finally reaches the destination.
  return 
{count}
;
}

The impact will also show up in centralized stores like Redux, which strive to reduce complexity sprawl but often seem to add to the problem. Signals eliminates both issues by making a centralized state simply another JavaScript file you create and import in the components. For example, here’s how a shared state module might look in Svelte:

// store.svelte.js
// This state exists independently of the UI tree.
export const counter = $state({
  value: 0
});

// We can even put shared functions in here
export function increment() {
  counter.value += 1;
}

Using this is just normal JavaScript:

  Click Me

Toward a Signals standard?

Historically, successful patterns that start out in libraries or individual frameworks often migrate into the language. Just think of how jQuery’s selectors influenced document.querySelector, or how Promises became part of the JavaScript standard.

Now, we are seeing it happen again with Signals. There is currently a proposal (TC39) to add signals directly to JavaScript. The goal isn’t to replace how frameworks work, but to provide a standard format for reactivity, which frameworks can then adopt.

Imagine defining a signal in a vanilla JavaScript file and having it drive a React component, a Svelte template, and an Angular service simultaneously. If adopted, this would move state management from a framework concern to a language concern—a big win for simplicity. Of course, it’s only a win if it goes well and doesn’t just spawn another way to do things.

Conclusion

For a long time, JavaScript developers have accepted a tradeoff in front-end development, exchanging the raw performance of direct DOM manipulation for the declarative ease of the Virtual DOM. We accepted the overhead because it made applications easier to manage.

Signals offers a way to grow beyond that compromise. While the roots of the pattern go back to the early days of the web, credit is due to Ryan Carniato and Solid.js for proving that fine-grained reactivity could outperform the VDOM in the modern era. Their success sparked a movement that has now spread to Angular, Svelte, and possibly the JavaScript language itself.

Signals gives JavaScript developers a declarative experience by defining state and letting the UI react to it, but with the surgical performance of direct updates. Returning to a push model, versus the pull model we’ve come to accept, lets us do more with less code. And with that, it may be the quest for simplicity in JavaScript is finally gaining traction.