Signals are reactive primitives for state management in UI frameworks. A signal holds a value. When the value changes, everything that depends on it updates automatically. This is the entire idea. It has been the entire idea since 1995. It will be the entire idea again in 2030, under a different name, with a new logo.
The concept arrived — or rather, re-arrived — circa 2022-2023, when Angular, Solid, Preact, and Vue all adopted signals as the solution to React’s re-rendering problem. The solution was: stop re-rendering everything. Instead, track which piece of state each piece of UI depends on, and update only that piece when it changes.
This is what Delphi’s TComponent did in 1995 with OnChange event handlers. It is what the Observer pattern described in 1994. It is what event emitters have done since the concept of events. The industry has been solving this problem for thirty years. It keeps forgetting the answer.
“Signals! Fine-grained reactivity! No virtual DOM! The UI updates EXACTLY what changed and NOTHING else!”
— The Caffeinated Squirrel, vibrating at a frequency that itself could be modelled as a signal
“You’ve just described an event handler.”
— The Lizard
The Reincarnation Cycle
The history of reactive state management in UI frameworks follows a pattern so regular it could be modelled as a signal that emits every five years:
| Year | Name | What It Did |
|---|---|---|
| 1994 | Observer Pattern (GoF) | Object notifies dependents when state changes |
| 1995 | Delphi OnChange | Component notifies dependents when state changes |
| 2004 | .NET INotifyPropertyChanged | Object notifies dependents when state changes |
| 2010 | Knockout.js Observables | Object notifies dependents when state changes |
| 2014 | RxJS Observables | Object notifies dependents when state changes, but with marble diagrams |
| 2022 | Signals | Object notifies dependents when state changes, but the blog posts are newer |
Each generation genuinely improves the ergonomics. The syntax becomes cleaner. The dependency tracking becomes more automatic. The integration with the rendering framework becomes tighter. None of this changes the fundamental mechanism, which is: when the value changes, call the callbacks.
“Every generation of programmers discovers the observer pattern, gives it a new name, and writes a conference talk.”
— A Passing AI, staring at a dependency graph that looked exactly like the one from 1994
Why Signals (Again)
Signals exist because React made a specific architectural choice in 2013: re-render everything, diff the result, apply the minimum changes. This was The Virtual DOM. React’s answer to “this re-renders too much” was useMemo, useCallback, React.memo — an expanding collection of escape hatches to prevent the framework from doing the thing it was designed to do.
Signals answer the problem by not having it. The framework tracks which signals are read during execution, automatically discovers dependencies, and updates only the DOM nodes that care. No dependency arrays. No manual subscription. No virtual DOM. It is measurably better than everything that came before.
It is still a callback. A very well-dressed callback.
“They built an entire tree-diffing algorithm… to avoid doing what we could have done by just… telling the DOM what changed?”
— The Caffeinated Squirrel, arriving at the insight approximately eight years after Solid did
The Convergence of 2023
The most remarkable thing about signals is not the technology but the sociology. In the span of roughly eighteen months:
- Solid shipped signals as its core primitive (it had them from 2018, but nobody was paying attention because nobody pays attention to things that are quietly correct)
- Angular added signals in version 16, replacing RxJS observables for component state
- Preact added signals as a first-class addon
- Vue pointed out that its reactivity system had been signal-based since 2020, and would everyone please stop acting like this was new
- Svelte 5 introduced runes (
$state,$derived), which are signals with a refusal to call them signals
The entire frontend ecosystem converged on the same primitive, independently, for the same reason: The Virtual DOM was the wrong abstraction, and everyone finally admitted it.
“I have watched this value change seventeen times. Each time, the correct DOM node updated. Only the correct DOM node. I have nothing to add. It simply works.”
— The Lizard, offering the highest praise available in its vocabulary
The Delphi Prophecy
In 1995, a Delphi developer could place a TEdit on a form, wire its OnChange event to a handler, and have the UI respond to exactly that change and nothing else. No virtual DOM. No dependency arrays. No useMemo. Just: when this value changes, run this code.
Thirty years later, the industry arrived at the same architecture, with better automatic dependency tracking and roughly forty-seven thousand npm packages to facilitate the journey.
“They are going to reinvent this again. Around 2029. They will call them ‘quantum observables’ or ‘reactive atoms’ or something with the word ‘fine-grained’ in it. And someone will write a blog post saying it’s entirely new.”
— A Passing AI, predicting the next cycle with the weary certainty of an entity that has read every blog post ever written
Measured Characteristics
- Years between reinventions of the observer pattern: ~5
- Distinct names for “notify dependents when state changes”: 14 (and counting)
- Frameworks that adopted signals in 2022-2023: 5
- Frameworks that claim they had signals first: all of them
- Lines of code to implement a signal: ~30
- Lines of blog posts explaining signals: ~3,000,000
- Conceptual difference from Delphi OnChange: negligible
- Ergonomic improvement over Delphi OnChange: genuine
- Probability of another reinvention by 2030: 97%
See Also
- React — The framework that made signals necessary
- The Virtual DOM — The abstraction signals made obsolete
- Delphi — The answer that arrived thirty years early
- Solid — Early to signals, ignored as is tradition
- JavaScript — The language in which the observer pattern is eternally rediscovered
