Redux has taken enough criticism over the years that some teams now avoid it reflexively, reaching for whatever’s newest - Zustand, Jotai, or framework-native signals - without actually diagnosing whether Redux was ever the real problem. Usually it wasn’t. The boilerplate people complain about was mostly a symptom of how Redux was taught circa 2018, not something inherent to the pattern.
What actually changed since the “Redux is too much boilerplate” era
Redux Toolkit fixed most of the legitimate complaints - no more hand-written action types, switch-statement reducers, or manually wired middleware. A modern Redux slice is genuinely concise. So the real comparison isn’t “old Redux vs. new alternatives,” it’s “current best-practice Redux vs. current alternatives,” and that comparison is closer than the discourse suggests.
Where signals and atomic state (Zustand, Jotai) genuinely win
The real advantage of signal-based and atomic state libraries isn’t less code, it’s more precise re-rendering. Redux’s default model re-renders any component subscribed to the store when relevant state changes, and while selectors mitigate this, it takes deliberate discipline to keep it efficient. Signals and atoms are reactive at a much finer grain by default - a component only re-renders when the specific piece of state it actually reads changes, with much less setup required to get that precision. For state-heavy, highly interactive UIs (real-time dashboards, collaborative editors, complex forms with many interdependent fields), this default fine-grained reactivity is a genuine engineering win, not just a smaller bundle.
Where Redux (or Redux Toolkit specifically) still earns its place
- Large teams needing enforced structure. Redux’s explicitness - actions, reducers, a single predictable store - is a feature for large teams where consistency matters more than minimal boilerplate. Newer libraries’ flexibility can become inconsistency across a big codebase without strong internal conventions enforced separately.
- Complex, traceable state transitions. Redux DevTools’ time-travel debugging and action logging remain best-in-class for genuinely complex state logic - financial transactions, multi-step workflows, anything where “what sequence of events led to this state” is a question you’ll actually need to answer during debugging or support.
- Existing large codebases. The migration cost of moving an established, working Redux codebase to a different state model is real and rarely justified purely on developer-experience grounds. We don’t recommend this migration unless there’s a specific, measurable performance problem driving it.
What we actually recommend for new projects
For most new applications we build, we default to a lighter atomic or signal-based approach (Zustand for simpler needs, or framework-native signals where the framework supports them well) because most business applications don’t have state complexity that needs Redux’s full ceremony, and the finer-grained reactivity is a genuine, free performance win for anything reasonably interactive. We reach for Redux Toolkit specifically when the project has real, complex, cross-cutting state that benefits from Redux’s explicit structure and debugging tools - think a project management tool with deeply interdependent state, not a typical CRUD dashboard.
The mistake we actually see most
Teams picking a state library before they’ve actually mapped what state their application has and how it changes. The library choice should follow from the shape of the problem, not precede it. We spend real time up front on this during architecture planning for frontend projects, because the wrong choice here compounds - it’s expensive to migrate away from later, in either direction.
If you’re scoping a new project or dealing with state management pain in an existing one, talk to us about what your actual state complexity looks like before picking a library based on what’s trending.