How many times have you inherited a React codebase built on Redux where someone had set up all this infrastructure to manage state that could've lived in a single component? I've counted hundreds across projects in Kuwait, Saudi Arabia, and the Gulf. Every time, the team tells me, "We chose Redux because that's what everyone uses."
By 2026, we've finally admitted that Redux was solving the wrong problem. We've built three different tools, each solving something specific. I want to save your team from choosing based on "which is simplest" instead of "what does your app actually need."
Let me be direct: you probably don't need state management at all. If you do, one of these three is right. The wrong choice doesn't break your product — it just adds friction you pay for every day.
What each tool actually solves
Zustand is for client state. User selections, filters, a modal's open/closed status, form data before you hit submit. It's a lightweight store where you describe your state shape, write simple functions to update it, and components subscribe to changes. It's honest about what it does — nothing more.
Jotai is also for client state, but it inverts the model. Instead of one store, you compose tiny atoms — think individual pieces of state. You can track dependencies between atoms, derive computed values, and combine them. It's philosophically closer to functional programming. Teams that value composability prefer Jotai. Teams that want a familiar model prefer Zustand.
TanStack Query (formerly React Query) isn't for state at all — it's for server state. The data your app fetches from an API. It handles caching, refetching, synchronization, and keeping your client in sync with your server. According to the TanStack Query documentation, it solves "the next generation of state management" specifically by removing server state from your client entirely.
Here's the truth: these aren't alternatives. You might use Zustand AND TanStack Query in the same app. You won't use Zustand and Jotai together — they solve the same problem in different ways.
When you actually need state management
In my experience leading projects across Kuwait and the Gulf, about 60% of the time a team asks about state management, they're really asking something else. "How do we keep our components from being a mess?" or "How do we pass data without prop drilling?" Real questions. State management is sometimes an answer, but not always the first one.
You don't need Zustand if your state lives in one or two components and nowhere else needs it. If you can pass it down as props without more than 2–3 levels of drilling. If your tree is under 30 components. You need it when you're building a dashboard, a management system, a real product a business in Kuwait is paying you to ship. Not a toy project.TanStack Query is different. You need it if you're fetching data from an API. Whether one call or fifty. Server state isn't yours anymore once it's on the server — it can change without you knowing. TanStack Query watches for that. Without it, you'll write race conditions and cache bugs until you run out of time and budget.
Jotai is the special case. You need it if your team has strong functional programming experience and actually wants that philosophy. Or if your derived state is complex enough that atoms make the code genuinely more readable. That's not always true. Plenty of smart teams build complex apps with Zustand and never miss Jotai.
| Aspect | Zustand | Jotai | TanStack Query |
|---|---|---|---|
| Solves | Client state (simple) | Client state (composed) | Server state (cache + sync) |
| Bundle size | 2.5 KB | 3.5 KB | 8–12 KB |
| Learning curve | Hours — familiar patterns | Days — atoms are new | Days — caching is new |
| Boilerplate | Minimal | Minimal (different style) | Minimal (queries + mutations) |
| DevTools | Browser extension | Browser extension | Standalone app or browser |
| Best for teams that value | Speed, simplicity, pragmatism | Elegance, composability, FP | Data consistency, correctness, offline |
When I'm advising teams in Kuwait, I see the same pattern every time. They spend weeks arguing about which library is "best," then spend months discovering the real issue was never the library — it was that nobody defined where state lives or how it flows.
The decision framework I use with clients
Stop me if you've done this: you're starting something new, you pick the shiniest library, you set it up with zero use cases in mind, and six months later you're still not sure why you need it.
Question 1: Are you fetching data from an API? Use TanStack Query. Don't overthink it. According to React's own documentation on data fetching, managing server state is one of the hardest parts of building UIs. TanStack Query exists to take that problem off your shoulders. You'll thank me in three months.
Question 2: Do you have client state (filters, modals, theme) that multiple components need? Pick Zustand unless your team has strong functional programming experience and actually wants Jotai. Both work. Zustand is easier to hire for. Jotai is more elegant if elegance matters to you. Sometimes it does.
Question 3: Do you have neither? Stop. Use React Context or prop drilling. Seriously. Don't add libraries before you need them. Three weeks into a project, when you actually have code, you'll know what you need.
The mistake I see most
Teams pick a library before they've written any code. Then they build for six months, and the state management they chose is either wrong or unnecessary. The library didn't fail — the planning failed. In 50+ projects across the Gulf, the teams that shipped fastest are the ones that wrote code for three weeks, realized they needed state management, picked the right tool, and refactored cleanly. Not the ones that started with a choice.
Honest caveats: where I wouldn't use each one
Zustand is tiny and simple. It doesn't have middleware or plugin ecosystems. If your business requires time-travel debugging, complex middleware pipelines, or serializing state to localStorage with validation, you'll find Zustand limiting. Not broken — just not designed for that. Redux (regrettably) is still better there.
Jotai is elegant, but the atom model takes time to learn. If your team is new to React or under deadline pressure, onboarding them to Jotai is slower than Zustand. Elegance matters less than shipping. Choose Zustand in that case.
TanStack Query solves caching and sync beautifully, but it doesn't help with authentication or complex request logic. You'll still need your own solution for those. And if your API returns data that's truly synchronous and never changes — a lookup table, a settings file — TanStack Query might be overkill. A simple fetch hook is fine.
What I tell clients in Saudi Arabia and the UAE
When a client asks us to build a new product, I ask: "How many developers? Are they in one room or distributed? What's your deadline?" Because the best library for a three-person team in Riyadh is different from the best library for a remote team of twelve across the Gulf. Zustand wins when speed matters. Jotai wins when your team has time to learn elegance. TanStack Query wins always for server state. But the real winner is always knowing what you're optimizing for before you commit to anything.
A realistic recommendation for your next project
If I'm advising a team in Kuwait building a business app — a dashboard, a management system, something real that someone's paying you to ship — here's what I'd say:
Start with TanStack Query for any data from your backend. It's not optional. It prevents bugs you haven't thought of yet. Use Zustand for client state (filters, selections, theme, UI state). It's simple enough that junior developers understand it, powerful enough that you won't hit a wall, and small enough that you don't feel guilty adding it. If your codebase grows and you inherit a team that loves functional patterns, migrate to Jotai later if you want. But starting with Zustand is the pragmatic choice.
Skip Redux. There are very few apps that justify the cognitive load anymore.
And if you don't need state management yet — because your component tree is small and data flows cleanly — don't add it. Wait until prop drilling actually becomes a problem. That day will come. When it does, you'll have enough context to choose right.
Why this matters for teams building in Kuwait and the Gulf
Every decision you make about libraries adds weight to your product. Not just in bundle size, but in the mental model your team carries every day. When you hire the next developer in Riyadh, they're learning your choices along with your code. Pick tools that are boring and well-understood. Innovation belongs in your business logic, not your boilerplate.
I've watched teams in the Gulf solve hard technical problems with simple tools, and I've watched teams everywhere add complexity before the problem existed. The teams that ship are the ones that stay pragmatic. Your next React project will be fine with Zustand and TanStack Query. That's not a compromise — it's good engineering.
If you're building software for a business in Kuwait or the Gulf and you're not sure about your state management choice, talk to us. We've shipped projects across the region using both, and we know what works under real deadlines and real budgets. Message us on WhatsApp to discuss your next project.