Most teams pick React state libraries from npm trends or conference hype. Also in this series: Why React Error Boundaries Are Class Components: one of the few React APIs that still requires a class.
That works until re-renders spike, boilerplate spreads, or onboarding slows new hires. The useful split is not “which logo is popular” but which architecture you are buying: a centralized store, an atomic graph, or a proxy snapshot model.
This post compares Redux and Zustand (centralized), Jotai (atomic), and Valtio (proxy)what each optimizes for, where it hurts, and how to choose without regret.
Centralized stores: Redux and Zustand
Centralized state means a single logical store (or a small number of stores) holding domain data. Components select slices and dispatch updates through a defined path. The mental model matches the diagram above: global state sits above tabs, routes, and feature panels so switching UI does not orphan data.
Redux
Redux is the explicit, event-sourced style: actions → reducers → predictable state. Ecosystem depth (Redux Toolkit, RTK Query, DevTools, middleware) is the main reason enterprises still standardize on it.
| Pros | Cons |
|---|---|
| Enforced data flow is easy to review in PRs and teach in onboarding docs. | Ceremony without RTK; even with RTK, new devs must learn slices, thunks, or listeners. |
| Time-travel debugging and structured logs map well to compliance-heavy environments. | Boilerplate pressure returns if you avoid conventions and RTK patterns. |
| Large-team scalability when you invest in patterns and codegen. | Selectors and memoization still require discipline to avoid broad re-renders. |
Zustand
Zustand keeps a minimal store API: subscribe, getState, setStateoften without Providers. It is centralized like Redux but defaults to less structure, which speeds small and mid-size apps.
| Pros | Cons |
|---|---|
| Tiny surface area; hook-based reads feel native in React. | Conventions are yourswithout guardrails, stores can become grab-bags. |
| Flexible middleware (persist, immer, devtools) without a framework lock-in story. | Very large teams may miss Redux’s uniform action/reducer story for cross-repo training. |
| Strong fit when you want one obvious place for cross-cutting client state. | Deep async flows still need clear patterns (no built-in “official” saga equivalent). |
When centralized wins: domain rules span many screens, several engineers touch the same data, you need auditable updates, or hydration/persistence is first-class. Redux leans enterprise process and tooling; Zustand leans velocity and low ceremony.
Atomic state: Jotai
Jotai models state as a graph of atomssmall units of state with explicit dependencies. Derived data is atoms that read other atoms. React subscribes per atom, so components tend to re-render only when their atoms change.
| Pros | Cons |
|---|---|
| Fine-grained subscriptions reduce unnecessary renders without hand-tuned selectors everywhere. | Mental model shift: thinking in graphs differs from “one big store object.” |
| Colocates derived state as composition of atomssimilar to graphs in Recoil’s family. | Large imperative workflows that touch many atoms at once need discipline. |
| Strong for UI-local and shared state mixed in one model. | Team documentation must explain atom layering to avoid spaghetti dependencies. |
When atomic wins: performance-sensitive UIs where isolate rerenders matter, dashboards with many independent dimensions, or when you prefer declarative dependency wiring over manual memoized selectors.
Proxy reactivity: Valtio
Valtio exposes mutable-looking plain objects that are tracked with proxies. You mutate properties; the library resolves snapshots and subscriptions for React. It feels closest to “just update my JS object.”
| Pros | Cons |
|---|---|
| Low cognitive overhead if your team already thinks in mutable domain models. | Proxy mental model: debugging requires understanding what is tracked vs plain objects. |
| Excellent for simple reactive objects and rapid prototyping. | Some patterns (nested structures, cross-cutting immutability expectations) need explicit docs on your team. |
| Small API; pairs well with TypeScript when patterns are stable. | May clash with codebases that treat deep immutability as a strict rule everywhere. |
When proxy wins: product and UX iteration speed matter more than formal action logs, or you want colocated mutable models with minimal glue code.
Architecture comparison at a glance
| Dimension | Centralized (Redux / Zustand) | Atomic (Jotai) | Proxy (Valtio) |
|---|---|---|---|
| Primary lever | One (or few) stores, explicit updates | Per-atom subscriptions | Mutable proxy + snapshots |
| Team scale | Strong for large teams with conventions | Strong when render cost is the bottleneck | Strong for small teams and fast iteration |
| Re-render story | Relies on selectors, shallow, structure | Built-in granularity via atoms | Property-level tracking |
| Learning curve | Redux steeper; Zustand gentle | New graph model | Familiar JS, proxy caveats |
| Debugging | Redux tooling gold standard | Atom dependency graphs | Snapshot / proxy awareness |
Decision checklist
- Do multiple features read and write the same domain entities? Prefer centralized (Redux or Zustand) and document update paths.
- Is unnecessary re-rendering your main pain? Prototype Jotai or tighten selectors in your current store before swapping everything.
- Do you want the least abstraction over plain objects? Try Valtio in strict boundaries (one feature slice) and measure.
- Is auditability or time-travel non-negotiable? Redux DevTools and explicit actions still earn their keep.
Popularity is a lagging indicator; architecture fit is leading. Match the library to how your team reasons about state, not only to download countsand reserve the right to mix local useState, React Query for server state, and one of these patterns for client-owned complexity.