You Don't Need Redux. You Probably Never Did.

I've seen it happen on almost every team I've been part of. Someone opens a new project, sets up the folder structure, and before a single feature is built — Redux is already in the package.json. Not because the app needs it. Because it feels like the responsible thing to do.

The real problem isn't Redux

Redux isn't bad. It's just almost never the actual solution to the actual problem. The real problem is that developers reach for global state before they've even asked why the state needs to be global in the first place. Most of the time, it doesn't. It needs to be lifted one level up, or colocated properly, or just... left where it is.

The state hierarchy nobody talks about

Before you reach for any state management library, work through the hierarchy: local state first, lifted state second, context third, external store last. Most apps never need to leave step two. The ones that do are usually managing genuinely complex async flows or cross-cutting concerns — not a user object and a boolean for a sidebar.

If you can't explain why the state needs to be global, it probably doesn't.

— Zaid Maraqa

When global state is actually the answer

Auth state. Theme. Cart contents in a large e-commerce app. Notification queues. These are real cases where something like Zustand — not Redux — handles it cleanly with a fraction of the boilerplate. The ecosystem moved on. Lighter tools exist. Redux Toolkit closed the gap on ergonomics, but for most projects it's still more ceremony than the problem deserves.

The habit worth building

Every time you're about to add global state, stop and ask: who actually needs this? If the answer is two sibling components, lift it to their parent. If it's three layers deep, context is fine. You don't earn architecture points for complexity. You earn them for solving the problem with as little machinery as possible — and knowing exactly why you need more when you do.