Redux Is Losing the Room — And Lighter State Tools Are Filling the Silence

There's a moment on most frontend teams when someone opens a Redux file for the first time and just... stares. The action types, the reducers, the middleware stack, the selectors — it's a lot. And for a lot of developers in 2024, that moment is the beginning of the end of their Redux relationship.

This isn't a hit piece on Redux. It genuinely solved real problems when it landed, and for certain use cases, it still does. But the frontend world has changed. Components are smarter, frameworks are more opinionated, and developers are increasingly asking a fair question: does the complexity I'm carrying actually match the complexity of my problem?

Spoiler: often, it doesn't.

Why Redux Made Sense — and Why That Logic Has Shifted

Back when Redux became the go-to state solution for React apps, the ecosystem was in a different place. React didn't have hooks. Context API was clunky and not built for high-frequency updates. There weren't many battle-tested options for managing shared state across large component trees.

Redux filled that gap. It gave teams a predictable, debuggable, centralized store. The DevTools were (and still are) genuinely excellent. The pattern was strict enough that even big teams could stay consistent.

But here's what happened: React grew up. Hooks arrived. Context got better. The community started building lighter abstractions. And suddenly, the boilerplate that felt like a necessary cost started feeling like unnecessary overhead.

When you're building a mid-sized SPA and you need three files just to update a user's name in the store, something has gone sideways.

Meet the Challengers: Zustand, Jotai, and Native React

The tools eating Redux's lunch aren't flashy — they're just simpler. And that simplicity is exactly the point.

Zustand has become the darling of teams that want a global store without the ceremony. You define your state and your actions in one place, consume them with a hook, and you're done. No providers wrapping your entire app. No action creators. No dispatch calls. The bundle footprint is tiny — under 2kb gzipped — and the mental overhead is even smaller. Teams report that onboarding new developers to a Zustand-powered codebase takes a fraction of the time compared to Redux.

Jotai takes a different angle. Instead of one big store, you work with atoms — small, composable pieces of state that components can subscribe to independently. This model aligns tightly with how React's reactivity already works, which makes it feel intuitive fast. It's especially good for cases where you have lots of isolated pieces of UI state that occasionally need to share data.

Native React solutions — specifically useReducer combined with Context — have also matured into a legitimate option for smaller apps. If your state logic isn't deeply complex and you don't need cross-cutting concerns like middleware or time-travel debugging, you might not need a library at all. Plenty of production apps are running just fine on built-in primitives.

The Real Performance Story

One area where lighter tools often win outright is bundle size and initial load performance. Redux Toolkit — the modern, recommended way to use Redux — still clocks in around 12-15kb gzipped when you factor in the full dependency chain. Zustand? Under 2kb. Jotai? Around 3kb.

For teams obsessing over Core Web Vitals and Time to Interactive, that delta matters. Especially on mobile connections, where every kilobyte of JavaScript costs you real time in parsing and execution.

Beyond bundle size, there's a subtler performance win: render optimization. Zustand's subscription model means components only re-render when the specific slice of state they care about changes. Jotai's atom model gives you similar granularity. With Redux, getting this right requires careful use of selectors and memoization — which is doable, but it's another layer of complexity that developers have to actively manage.

Developer Experience: The Factor Teams Don't Talk About Enough

Here's something that doesn't show up in benchmarks but absolutely shows up in sprint velocity: how much time your team spends fighting the tool instead of building the product.

Redux's learning curve is real. The mental model — actions, reducers, selectors, middleware, thunks or sagas — takes time to internalize. For senior developers who've been in the ecosystem a while, it's second nature. For junior developers or folks coming from other frameworks, it can be a serious ramp-up.

Zustand and Jotai have much flatter curves. The APIs are small, the patterns are straightforward, and the documentation is approachable. Teams that have made the switch frequently describe the experience as freeing — not because Redux was bad, but because the cognitive load dropped noticeably.

That said, Redux's DevTools are still a differentiator. If you need detailed action history, time-travel debugging, or the ability to replay state changes in production bug reports, Redux's tooling is hard to beat. Zustand has some DevTools support, but it's not at the same level.

A Framework for Choosing the Right Approach

So how do you actually decide? Here's a rough decision tree that works for most teams:

Start with native React (useState, useReducer, Context) if your app is small-to-medium, your state isn't deeply shared, and you don't have complex async flows. Don't reach for a library until you feel the pain that library solves.

Reach for Zustand when you need a global store that multiple components access, you want to avoid prop drilling, and you don't want the overhead of Redux's patterns. It's a great default for most mid-sized apps.

Consider Jotai when your state is naturally granular — lots of small, semi-independent pieces that occasionally need to interact. It's also a solid fit for teams that already think in React's model and want something that extends that mental model rather than replacing it.

Stick with Redux Toolkit if you're on a large team working on a complex, long-lived application where consistency and tooling matter more than simplicity. If you already have Redux in your codebase and it's working, the ROI on migrating might not be there.

The Bigger Takeaway

The shift away from Redux isn't really about Redux being bad — it's about the frontend ecosystem maturing to the point where simpler tools can handle more use cases than they used to. The right state management solution is the one that matches the complexity of your actual problem, not the one that's most impressive on a resume or most familiar from a previous job.

At FrontalCode, we're big believers in reaching for the simplest tool that gets the job done. Sometimes that's Redux. More often these days, it's something lighter.

Pick the tool that lets your team ship faster, debug easier, and onboard quicker. That's the one that's winning — regardless of what the ecosystem was doing five years ago.