State Management Evolution

Written by Backbone Tutorials Team

Last updated: June 2026 · 10 min read

State management has its own history, separate from the frameworks that host it, and that history is really a series of attempts to answer one question: when something changes, how do you know what else needs to change, and in what order. Backbone answered it with Models and events. Flux answered it with one-way data flow. Stores answered it with a single source of truth. Signals answered it with fine-grained tracking. Each answer fixed a specific problem with the one before, and seeing the sequence makes today's tools feel inevitable rather than arbitrary.

This guide traces that evolution from Backbone Models to signals and explains how to choose an approach now.

Why state management became a discipline

State management grew from an afterthought into a named discipline because, as applications became more interactive, keeping data consistent across the interface became the hardest part of building them.

When data lives in many places at once

In a simple page, state is small and local. In a complex application, the same piece of data may appear in several places, be edited from several others, and need to stay consistent everywhere. Without a deliberate approach, updates race each other, parts of the interface disagree, and bugs become hard to trace. State management is the set of patterns that make these changes predictable, and every approach below is an attempt to impose that predictability.

Backbone Models as early state

Backbone was among the first widely-used libraries to pull state out of the DOM and give it a dedicated home, which was a significant step at the time.

A single source of truth, wired by events

A Backbone Model held data and emitted a change event when it was modified, and Views listening to that event updated themselves. This established the principle that data should live in objects rather than in markup, a principle the Backbone.js guide explains in full. Its limitation was that the connections between Models and Views were manual, so in a large app the event graph grew tangled and the order of updates became hard to reason about.

The Flux pattern and unidirectional flow

Flux emerged to tame the tangle by imposing a strict, single direction on how data moves through an application.

Making update order predictable

In a unidirectional flow, changes are expressed as actions that flow through a central handler to update state, and the interface re-renders from that state. Crucially, the interface never mutates state directly; it dispatches an action and waits. This one-way discipline made the order of updates predictable, which the tangled two-way connections of event-based systems could not guarantee. The shift from imperative event handling to declarative flow parallels the move described in MVC versus components.

Stores and centralized state

Stores took the Flux idea and packaged it into reusable containers that became the standard way to share state across an application.

One place to read and change shared data

A store is a centralized container that holds shared state, exposes it to any component that needs it, and provides controlled ways to change it. Because there is a single source of truth, the question of which copy of the data is correct disappears. Stores made large applications tractable by giving shared state one home and one set of rules, though heavyweight stores added boilerplate that lighter approaches later tried to remove.

Signals and modern state

Signals brought fine-grained reactivity to state management, reducing both the boilerplate of stores and the recomputation of earlier reactive systems.

State that knows its own dependents

A signal is a piece of state that tracks exactly which parts of the interface depend on it, so changing it updates only those parts automatically. This removes most of the manual subscription code that stores required and avoids re-running large sections of the interface. Signals have spread across many frameworks because they combine the predictability of centralized state with the precision of fine-grained updates, a convergence detailed in reactivity systems.

Choosing a state approach today

With several generations of tools available, the right choice depends on the scale of the state problem you actually have.

Matching the approach to the scale

Small applications need little more than state local to components, and reaching for a heavy store there adds complexity without benefit. As state becomes genuinely shared across many parts of an application, a store or signals-based approach earns its keep by giving that shared state a single source of truth. The honest guidance is to start simple and add structure only when the lack of it causes real problems, a principle that runs through the whole modern frameworks cluster.

Read next: component-based architecture, or the Modern Frameworks hub.