Redux is not dying. It is simply no longer being hired.
Two charges were brought. On the first — that Redux is dead — the evidence does not support conviction and the court finds for the respondent. On the second — that Redux has a job to do in this application — the court finds against. A library can be perfectly healthy and still be the wrong hire.
Count I — dismissed
"Redux is abandonware."23.6M weekly npm downloads [2]. Shipping releases through v2.12.0 in May 2026 [8]. Growing 8.4× over three years. The "Redux is dead" genre is wrong, and this court will not join it.
Count II — sustained
"Redux earns its place initenium-ui."
An admin console and a file manager over a REST API have none of the problems Redux exists to solve — by Redux's own list [1]. Almost all of its "state" is a cache of server data, which is not what Redux is for.
The court's order: take TanStack Query ⭐ 50k for server state [31] and a small Zustand ⭐ 59k store for the client-state residue [23]. Leave to reopen is granted on any of the six findings in Part II below — those are real, and this court means them.
The numbers were entered into evidence
Three exhibits. None of them says "dead". All three say "not winning new work".
Exhibit A — weekly npm downloads, w/c 5 July 2026
OvertakenOvertaken on both axes: 1.55× by Zustand [3], 2.6× by TanStack Query [4]. Zustand crossed RTK during 2024–25 and the gap has widened since [5].
Exhibit B — monthly growth, Jun 2023 → Jun 2026
Growing, but lappedRedux grows. The alternatives grow three to four times faster from a smaller base [5]. Absolute health, relative collapse — these are compatible facts, and most of the internet conflates them.
Exhibit C — State of React usage, 2023 → 2025
The flatlineThe flat red line is the whole case. RTK is not losing its installed base — it is failing to recruit [6] [7]. Corroborating: one maintainer carries the commit graph (1437 commits vs 924 / 447 / 346) [9], and the RTK Query 2.x/3.x roadmap is still an open discussion thread rather than a shipped plan [28]. Maintenance-plus-increments, not expansion.
The maintainers were called. They did not help their side.
Two statements, routinely conflated. One is a how. The other is a whether.
If you are writing any Redux logic today, you should be using Redux Toolkit to write that code.
Not all apps need Redux… It's not designed to be the shortest or fastest way to write code. There are more concepts to learn, and more code to write… don't use Redux until you have problems with vanilla React.
Prefer writing integration tests with everything working together… the Redux code can be treated as an implementation detail of the app, without requiring explicit tests for the Redux code in many circumstances.
RTK Query deliberately does not implement a cache that would deduplicate identical items across multiple requests.
Redux's official list of when it is useful: state needed in many places; state updated frequently; complex update logic; a medium-to-large codebase worked on by many people; a need to see how state changed over time [1]. Score an admin console plus a file manager over a REST API against that list honestly, and it hits roughly none of them.
The framing that lands for a .NET architect: Redux is MediatR plus an event log, for the browser. Every mutation is a named, serialisable command flowing through one dispatcher, middleware as the pipeline. Genuinely valuable — when you have the problem. Applied to "fetch a list of users and show it in a table", it is CQRS on a CRUD form.
Three moats, tested under oath
These were Redux's differentiators. Each one is now available without Redux.
DevTools and time-travel debugging
Moat collapsedThe claim
Only Redux gives you a named action log and a scrubbable state timeline. This was, for years, the best single argument for adopting a store.
Under cross-examination
Zustand's devtools middleware "lets you use Redux DevTools Extension without Redux and enables time-travel debugging" [15]. Redux DevTools ⭐ 14k is a separate project Redux no longer owns exclusively [27]. One middleware wrap.
"Pure reducers are ideal for TDD"
Moat collapsedThe claim
A reducer is a pure function of (state, action) → state. Nothing is easier to unit-test. A TDD mandate therefore favours Redux.
Under cross-examination
Redux's own testing guide tells you not to write those tests [16]. The recommended Redux test is: render the tree with a real store, mock the network — exactly the test you would write against a Zustand store with Testing Library. A TDD mandate is not an argument for Redux.
RTK Query as the data layer
Circular — inadmissibleThe claim
RTK Query is a first-class caching data layer, so adopt Redux and get the cache for free.
Under cross-examination
The official comparison page positions RTKQ for teams who already use Redux and need DevTools/ecosystem integration [12]. It is an excellent reason to keep Redux. It is a bad reason to introduce it: you would adopt a store you don't need in order to get a cache you can have standalone — from a library with 2.6× the downloads and no store tax.
What React 19 actually took away
Most blog posts are imprecise here. Half the "React 19 killed Redux" argument does not even apply to a Vite SPA.
| React 19 feature | Redux remit it erodes | Applies to a Vite SPA? |
|---|---|---|
Actions + useActionState |
Pending flags, error state, form-submit thunks [13] | ✓ Yes — client-only React 19 |
useOptimistic |
Optimistic-update middleware and manual rollback; React reverts automatically on error [14] | ✓ Yes |
use() |
Reading a promise in render, with Suspense | ⚠ Yes, but — it needs a cache to suspend against, and React ships none for a client SPA. TanStack Query is that cache. |
| Server Components / Server Actions | The whole server-state layer | ✗ No — RSC needs a supporting framework/bundler [13]; an Nx + Vite SPA has none. |
So the mutation-side ergonomics are yours for free, and they delete the single most common reason people historically wrote thunks. The RSC half applies not at all — which is precisely why you still need a real server-state library, and why the answer is TanStack Query rather than "React 19 handles it". Its own docs draw the boundary: it is "a server-state library… not a replacement for local/client state management", and after adopting it "most of your once seemingly global state really wasn't global at all" [31]. Practitioners put server state at 60–80% of the Redux code in a typical data-driven app [26]. Delete that, and what remains rarely justifies a store.
Six findings on which Redux still wins outright
This is not a courtesy paragraph. Each of the six below is a bar Redux clears that lighter tools cannot — and if a future Forge frontend clears any one of them, this judgment is vacated and Redux is the right answer. The finding against Redux is narrow, and it is about this application, not about Redux.
1 · Undo/redo over a large state tree
The action log is the undo stack. redux-undo ⭐ 2.9k wraps a reducer and you get undo/redo for free [19]. Retrofitting this onto a mutable store is a rewrite, not a feature.
Design tools · canvas & diagram editors · spreadsheet-likes
2 · Complex cross-cutting client state with many writers
"When did this slice change, and where did the data come from" is the exact question Redux was built to answer [32] [1]. Nothing lighter answers it as cleanly.
Collaborative editors · trading & ops dashboards · wizards whose steps mutate each other
3 · Logic that must run outside React
Listener middleware and sagas react to actions, not to components — WebSocket push, background sync, cross-cutting analytics, offline queues. Officially cited as an RTK Query advantage too [12].
Push-driven UIs · offline-first · upload queues
4 · Heavy derived state
Reselect's createSelector with a minimal store and everything else computed [17]. The court notes this is the weakest of the six: Reselect ⭐ 19k works standalone [18], and useMemo covers most cases.
Analytics grids · pivot tables
5 · Large teams needing enforced conventions
The official Style Guide plus createSlice gives you one lint-able, reviewable way to mutate state [25]. Genuinely worth the ceremony at 10+ developers on one app.
Enterprise frontends · many teams, one store
6 · Session replay and bug repro from a serialised action log
Ship the action list from a user's session, replay it, reproduce the bug. Nothing else in the ecosystem does this as cleanly — the serialisability of every mutation is the whole point.
Support-heavy products · regulated audit trails
Five clear noes and one "not yet". That is why the ruling goes the way it does — not because Redux lost an argument, but because itenium-ui presents none of the facts on which Redux wins. If a future Forge frontend is an editor rather than an admin console, revisit this. Redux is the right tool for editors.
OpenAPI codegen — and why it fails on the facts
Itenium.Forge exposes Swagger/OpenAPI, so typed-client generation is genuinely on the table, and RTK Query has a first-party answer: @rtk-query/codegen-openapi generates a fully typed API slice with hooks straight from the schema [20]. That is a real advantage. It evaporates on inspection, because the non-Redux side has the same thing — with a better testing story.
| Generator | Output | Stars |
|---|---|---|
@rtk-query/codegen-openapi |
Typed RTK Query API slice + hooks [20] — and a Redux store you must adopt to use them | ⭐ 11.2k (in RTK) |
| Orval | Typed TanStack Query hooks + MSW mocks out of the box [21] | ⭐ 6.2k |
| Hey API | Typed client + TanStack Query plugin; lighter, plugin-based [22] | ⭐ 5.1k |
Orval's built-in MSW mock generation is a direct hit on a TDD mandate: generated mocks from the same schema that generates the client. Against a testing-first shop that is a better story than RTK's codegen, not a worse one. The respondent's strongest count is matched and beaten.
It is ordered as follows
Server state → TanStack Query ⭐ 50k
Caching, dedup, retries, invalidation, use()-friendly suspense [24]. This eats 60–80% of what people used Redux for [26].
Escape hatch, reserved
If the client store ever grows past a dozen interdependent slices with complex update rules, Zustand ships a redux-style middleware — you can adopt reducer/action discipline without adopting Redux. Reselect works standalone if derived state gets heavy [18]. And Jotai ⭐ 21k remains the atomic-state alternative if the residue turns out to be fine-grained rather than global [30].
The one caveat worth naming
Choosing against Redux means choosing a stack whose pieces are maintained by small teams too. Zustand and Jotai are both pmndrs; TanStack is Tanner Linsley's org. You are not trading a bus-factor-of-one [9] for a bus-factor-of-many — you are trading it for a different small team with steeper adoption momentum.
What you do buy is exit cost. A Zustand store is a plain hook and a few hundred lines. Ripping out Redux is a project. Ripping out Zustand is an afternoon. For a greenfield pick with genuine uncertainty about where the app lands, that asymmetry is the deciding argument — and it is the argument this judgment ultimately rests on.
The community says the same thing more plainly: "Redux isn't dead, but in 2026, maybe we shouldn't be using it without thinking, like opening jQuery to create a dropdown" [29].
Consolidated with
This opinion is one of six filings under the Itenium.Forge state-management expedition.
Cited in this judgment
32 sources — npm registry counts, official documentation, maintainer statements, one survey, three community readings.