You Don't Need Redux: State Management for React Developers Who Are Tired of Boilerplate

Every React developer has been there. You start a new project, and before you've written a single component, someone asks: "Should we use Redux?"

After building four production applications — a fintech dashboard, an ERP panel, a social app, and this portfolio — using Redux, Zustand, Jotai, and plain Context, I can tell you exactly when each one makes sense.

The Honest Comparison

Plain Context + useReducer

Use when: Your app has fewer than 5 state slices that need to be shared globally.

This is what I used for this portfolio. The state is simple: which section is active, theme preference, and a few animation states. Adding Redux here would be like putting a jet engine on a skateboard — technically possible, but profoundly unnecessary.

const [activeSection, setActiveSection] = useState("terminal")
const [isDark, setIsDark] = useState(true)

That's it. That's the entire state management. No providers, no actions, no reducers, no middleware.

When it breaks down: When you have deeply nested components that need the same state. Prop drilling through 5+ levels is a code smell.

Zustand

Use when: You have 5-15 state slices, need simple global state, and want minimal boilerplate.

This is the sweet spot for most medium-sized applications. Our WidePay financial dashboard uses Zustand, and it handles 12 state slices effortlessly.

const useTransactionStore = create((set) => ({
  transactions: [],
  filters: { date: null, status: null },
  setFilters: (filters) => set({ filters }),
  addTransaction: (tx) => set((s) => ({ transactions: [...s.transactions, tx] })),
}))

Why it works: No providers, no boilerplate, TypeScript works out of the box, and the bundle size is 1.1KB gzipped. The API is close enough to React's built-in hooks that onboarding is seamless.

When it breaks down: When you need complex derived state, time-travel debugging, or middleware chains. For 90% of apps, you'll never hit these limits.

Jotai

Use when: You have atomic state that updates independently, and you want surgical re-renders.

Jotai takes the "atom" approach from Recoil but with a much smaller API surface. Each piece of state is an atom, and components only re-render when the atoms they subscribe to change.

Where I used it: The Ebn Balady social app had complex feed state — infinite scroll, optimistic likes, real-time notifications. Jotai atoms let us avoid re-rendering the entire feed when a single like state changed.

When it breaks down: When atoms start depending on each other in complex ways. The derived atom syntax gets unwieldy fast.

Redux Toolkit

Use when: You need middleware, time-travel debugging, or your team already knows Redux and you have a large app with many state interactions.

I still use Redux Toolkit for the ERPNext CRM customization at Jadwaa because:

• The team already knew Redux from their previous projects
• We needed middleware for API caching (RTK Query)
• The dev tools and time-travel debugging saved us countless hours during development
• The strict predictability was important for financial data flows

When it's overkill: Anything smaller than a large enterprise application. If you're building a todo app, a blog, a portfolio, or a simple dashboard — Redux is not worth the cognitive overhead.

The Decision Framework

Ask yourself these questions in order:

1. Can you count your global state slices on one hand? → Use Context + useReducer
2. Do you need simple global state with minimal setup? → Use Zustand
3. Do you have many independent state atoms and need precise re-renders? → Use Jotai
4. Do you need middleware, dev tools, or RTK Query? → Use Redux Toolkit
5. Are you building a portfolio site? → Stop overthinking it, use useState

The best state management library is the one that lets you ship features without making you think about state management. For most applications, that's Zustand or nothing.