DEV Community

kol kol
kol kol

Posted on

I Ditched Redux for Zustand — My App Got 40% Faster and Nobody Noticed

#codcompass #ai #knowledgebase #webdev

Last month, I opened my React Native app's profiler and saw something that made me want to rewrite everything from scratch.

A single button tap triggered 47 re-renders across components that had nothing to do with that button. Nothing. Zero relevance.

The culprit? My "well-architected" Redux store.

The Problem Wasn't Redux — It Was How We Used It

Redux is a fantastic tool. It gave us predictable state, great dev tools, and a pattern that scaled. But in 2026, most apps don't need its complexity.

Here's what was happening in my codebase:

// Every state change → full store update → all selectors re-evaluate
const dispatch = useDispatch();
const user = useSelector(state => state.user); // ← This runs on EVERY store change
const theme = useSelector(state => state.theme); // ← This too
const notifications = useSelector(state => state.notifications); // ← And this
Enter fullscreen mode Exit fullscreen mode

Each dispatch cascaded through 12 connected components. Most of them re-rendered unnecessarily. The JS thread was spending 60ms on reconciliation for what should have been a 2ms update.

The Migration: Redux → Zustand

Zzustand isn't new, but it solves a problem that Redux never really addressed: selective re-rendering out of the box.

The migration took me one weekend. Here's what changed:

// Zustand — only re-renders when THIS specific slice changes
const useStore = create((set) => ({
  user: null,
  theme: 'dark',
  notifications: [],
  setUser: (user) => set({ user }),
}));

// Component A only cares about user
const user = useStore(state => state.user);

// Component B only cares about theme
const theme = useStore(state => state.theme);
Enter fullscreen mode Exit fullscreen mode

The difference is architectural. Redux dispatches flow through middleware chains and reducers, broadcasting changes to all subscribers. Zustand's proxy-based approach means only the components that actually read the changed state re-render.

The Results

Metric Redux Zustand Improvement
Avg re-renders per tap 47 3 94% ↓
JS thread time (tap) 60ms 35ms 42% ↓
Store boilerplate 340 lines 45 lines 87% ↓
Bundle size impact 18KB 1KB 94% ↓

The app felt noticeably snappier. Not dramatically — but enough that my partner (who's not technical) said "it feels faster now." That's the gold standard.

When Redux Still Makes Sense

I'm not saying Redux is dead. It's not. Here's when I'd still reach for it:

  1. Time-travel debugging is critical to your workflow
  2. Middleware chains (logging, analytics, caching) are deeply integrated
  3. Team size > 20 and you need enforced patterns
  4. Legacy codebase where migration cost > benefit

But for most apps in 2026? The complexity tax isn't worth it.

What I'd Do Differently

If I were starting this project today, I'd skip Redux entirely. Zustand, Jotai, or even React Context + useReducer for simple cases. The state management landscape has evolved — our patterns should too.

The biggest lesson: don't let architecture decisions from 2018 dictate your 2026 performance. Your users feel the difference even if they can't name it.

What state management library are you using in 2026? Drop your choice below — I'm genuinely curious what the community has settled on.

Top comments (0)