A senior engineer’s pragmatic take on the Redux vs. Zustand debate, moving beyond “just use it” to explain the real-world trade-offs in boilerplate, team velocity, and project scale.

Redux vs. Zustand: A Senior Engineer’s No-BS Guide to a Pointless War

I remember a project back in 2021. We called it “Project Chimera.” We spent three sprint planning meetings—that’s a solid six hours of seven engineers’ time—arguing about state management. The junior devs, fresh from bootcamps, were all-in on Redux Toolkit. The mid-levels had heard whispers of a new thing called Zustand and were chanting “less boilerplate.” We were completely paralyzed. The feature lead just wanted to ship the damn thing. This whole “just use Zustand” conversation isn’t a technical problem; it’s a team velocity and cognitive overhead problem, and I’m tired of seeing teams get stuck in the mud over it.

The “Why”: What’s the Actual Fight About?

Let’s be clear: this isn’t about which one is “better.” They both manage state. The real friction comes from a fundamental difference in philosophy. Redux was born from a need for a predictable, bulletproof, and auditable state container for massive applications. It forces you into a specific pattern: actions, reducers, dispatchers, selectors. This structure, its greatest strength, is also its biggest curse: the boilerplate.

Zustand, on the other hand, asks a different question: “What’s the absolute minimum you need to get a shared, reactive state hook?” It throws out the ceremony and gives you a simple, unopinionated hook-based store. You’re trading Redux’s rigid guardrails for Zustand’s speed and flexibility.

So when someone says “just use Zustand,” they’re not saying “Redux is bad.” They’re saying, “I’m tired of writing three files to update one piece of state, and for 90% of apps, that’s overkill.”

The Solutions: Picking Your Weapon for the Right War

There is no “one right answer.” There’s only the right answer for your team, your project, and your sanity. Here are the three paths I see teams take.

Solution 1: The Incumbent – Stay with Redux Toolkit (and own it)

There is absolutely nothing wrong with sticking with Redux Toolkit (RTK). If a junior engineer tells me they’re frustrated with the “just use Zustand” crowd, my first question is, “Why do you like Redux?” If the answer involves the DevTools, the strict unidirectional data flow, or the robust middleware ecosystem (like Redux Saga or RTK Query), then that’s a perfectly valid reason.

When to choose this path:

• Large, Complex State: Your application state looks like a city map, with dozens of interconnected domains.
• Big Teams: You have many developers of varying skill levels working on the same codebase. RTK’s rigid structure prevents cowboys from going rogue.
• Need for Auditing: You absolutely need to time-travel debug and have a crystal-clear log of every single state change that has ever happened.

Here’s a standard RTK counter slice. It’s verbose, but it’s also explicit and easy to follow for anyone familiar with the pattern.

// features/counter/counterSlice.js
import { createSlice } from '@reduxjs/toolkit'

export const counterSlice = createSlice({
  name: 'counter',
  initialState: {
    count: 0,
  },
  reducers: {
    increment: (state) => {
      state.count += 1
    },
    decrement: (state) => {
      state.count -= 1
    },
  },
})

export const { increment, decrement } = counterSlice.actions
export default counterSlice.reducer

Darian’s Take: Don’t let the hype train make you feel bad for using a tool that works. If Redux Toolkit solves your team’s problems and keeps your complex app maintainable, that’s a win. The goal is to ship stable products, not to use the trendiest library.

Solution 2: The Challenger – Actually “Just Use Zustand”

Okay, let’s look at why people are so fanatical about this. This is the “get it done” option. You need some global state—maybe for user authentication, a shopping cart, or a theme toggle—and you want it working in five minutes. This is where Zustand shines. It’s minimal, it’s fast, and it feels like a natural extension of React hooks.

When to choose this path:

• Small to Medium Apps: Most projects don’t need the heavy artillery of Redux.
• Rapid Prototyping: You need to move fast and aren’t concerned with building a decade-long enterprise monolith from day one.
• Boilerplate Fatigue: Your team is senior enough to manage state without strict guardrails and is actively slowed down by Redux’s ceremony.

Now, let’s build the exact same counter from before, but in Zustand.

// store/counterStore.js
import { create } from 'zustand'

export const useCounterStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
  decrement: () => set((state) => ({ count: state.count - 1 })),
}))

// In your component:
// import { useCounterStore } from '../store/counterStore'
// const { count, increment } = useCounterStore()

That’s it. That’s the entire thing. The store definition and the actions are all in one tiny, readable block. No providers, no dispatching, no action creators. You just import the hook and use it. This is why people are excited. It’s a massive reduction in cognitive load for a simple task.

Solution 3: The Pragmatist’s Hybrid – Use the Right Tool for the Right State

This is where most senior engineers I know land. The idea that you must pick ONE global state manager for your entire application is a fallacy. Not all state is created equal.

• Global State: Truly application-wide state. User info, permissions, internationalization settings. This is a perfect fit for Zustand (or Redux, if you’re already there). It’s data that many disconnected parts of your app need.
• Feature State: State that belongs to a specific, complex feature, like a multi-step form or a data table with complex sorting/filtering. This might live in a Zustand store or even just React’s own useReducer hook.
• Component State: State that belongs to a single component or its immediate children. A modal’s open/close status, an input’s value. This should ALMOST ALWAYS be managed with useState or the Context API. Shoving this into a global store is how you create a slow, tangled mess.

Warning: The biggest mistake I see teams make is putting everything in their global store. Just because you can doesn’t mean you should. Using Context API for localized state that doesn’t change often (like a theme) is a perfectly professional and clean solution. Don’t let the “Context is slow” talk scare you away from using it correctly.

The Head-to-Head Comparison

When in doubt, a simple table can help clear things up.

Final Word: Stop Arguing, Start Building

So, should you switch from Redux? Maybe. Maybe not. The next time someone tells you to “just use Zustand,” don’t get defensive. Instead, ask them: “What specific problem on this project do you think Zustand will solve better than our current setup?” If they can give you a concrete answer related to developer friction, boilerplate, or unnecessary complexity, then it’s a conversation worth having. If they can’t, then they’re just chasing trends.

Your job as an engineer isn’t to use the coolest tools. It’s to solve business problems effectively. Pick the tool that lets you and your team do that best, and get back to shipping.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions