The Absolute State of Management - Infrequently Noted
Skip to main content
Series
Reckoning
Browser Choice Must Matter
The Performance Inequality Gap
Effective Standards Work
Recently
The Absolute State of Management
Abject Praise
The Web Is An Antitrust Wedge
Naked Power
The Performance Inequality Gap, 2026<br>'25, '24, '23, '22, '21, '20, Earlier
Popular
Abject Praise
The Performance Inequality Gap, 2026
If Not React, Then What?
Misfire
It is by no means the gravest linguistic crime of the React epoch,1 but "state management" grates like nails on chalkboard. A Socratic dialogue I keep having about it goes something like this:
me: This UI is far too heavyweight for what it does, have you considered not using React?
them: But how will we do state management without React?
me: What do you mean? are reactive.
them: React manages state in our app.
me: It does? Then what are for?
them: Oh, those manage state.
me:
The libraries that trigger this "Who's on First?" routine include:
MobX, which promises "simple, scalable state management."
Satchel, apparently, "is characterized by exposing an observable state that makes view updates painless and efficient"
Recoil, billed as "a state management library for React"
Jotai, which pledges "primitive and flexible state management for React"
XState, a "state management and orchestration solution for JavaScript and TypeScript apps"
Apollo, promising "a comprehensive GraphQL state management library for JavaScript"
Redux, tagline: "a predictable state container for JavaScript apps."
TanStack Store, "a framework-agnostic state primitive for immutable updates"
Zustand, described as the "🐻 bear necessities for state management in React"
Contrasts sharp enough to cut softened butter.2
Suffice it to say, the ecosystem has not picked a winner. Indeed, I regularly see several of these libraries on a single page. But even one would seem too many, given that we're adding a second "state management" system to a framework that spills considerable documentation ink chest-beating about its state management facilities.
One of the following must be true:
React is a state management system and someone has smuggled in a duplicative dependency we can jettison.
React is an inadequate state management system and we should stop trusting it with an ill-defined subset of the "state management" problem.
React is not a state management system and we should stop pretending otherwise.
But in the to-and-fro of consulting engineering one can't just say as much, for fear of offence against frameworkist articles of faith.3
Thankfully, this is a blog post, so we can cut to the chase and admit that none of these tools manage state.
They might encapsulate state. They might even filter or transform state updates. But they do not, in any meaningful way, manage it.
Instead, they locally propagate notifications about state changes and, in some cases, post-process them or serve as caches.4 Conceptually, they are expressively equivalent to event buses and pub/sub systems, which are better understood as message passing backplanes.5
To understand the difference between state propagation and state management, we need to add the time dimension. React-centric "state management" libraries handle time the way C++ does for multithreaded code — which is to say, it's left as an exercise to the reader.6
Systems without a built-in conception of time and ordering can be subject to temporal effects. They can even synthesise compound state out of unordered, un-timestamped updates. But they occupy a world of hopes and dreams when it comes to asserting affirmative management of state because managing state means correctly applying changes over time and resolving conflicts.
Then and Now and When
A large fraction of the problems from overgrown React and Redux attempts at "state management" spring from the same wellstone: updates to the state propagation systems come from a variety of sources, with varying frequency and specificity, and pure propagation systems crumble under the incidental complexity that results from trying to sort out the consequences with only an event bus abstraction to work with.
At bottom, this is the same problem of managing data across multiple machines, which means managing it across time that spans from the past, to the current moment, as well as the future.
This insight is important because it allows us to consider what's currently in memory vs. the same app rebooted at some future point without losing our minds. A future instance of an app is conceptually the same as the app booting on an entirely different computer. Getting crisp on this is the key to throwing out childish notions of "state management" and replacing them with tools that are fit for purpose.
Systems that manage state — rather than merely propagating or filtering it — have built-in concepts of time and order. Instead of hoping that everything is happening in some window that we can squint...