Confession: I spent about two hours last Tuesday arguing with a coworker about Zustand vs Redux Toolkit. We were both wrong in slightly different ways. He wanted to Redux-ify a tiny admin dashboard that had exactly one piece of shared state. I wanted to Zustand-ify a multi-tenant billing UI that had a genuinely complex reducer graph, undo\/redo, and three engineers touching it at once.<\/p>\n
We swapped opinions halfway through the argument, which is the kind of thing that only happens after too much coffee. Neither library is “better.” The interesting question is which one you should reach for on the app you’re actually building this month.<\/p>\n
I’ve now shipped both in production for a few years. This post is my honest map of which one I pick, when I pick the other one, and the specific moment I realized my defaults were wrong.<\/p>\n
I have nothing against Redux Toolkit. It’s the most polished version of Redux that has ever existed. But here’s the thing I keep running into on small-to-medium apps.<\/p>\n Even after Then a It’s not offensive. It’s just a lot of typing for one boolean.<\/p>\n Zustand does the same job with less machinery. There’s no Provider, no dispatch, no typed hooks helper. You define a store as a hook, and the hook is the store.<\/p>\n In a component:<\/p>\n That selector function on the hook is the important part. Zustand only re-renders the component when the slice you selected actually changes, so you get the “only re-render what changed” behavior for free without wrapping anything in The whole library ships in a few kilobytes. The Redux Toolkit + React Redux pair is meaningfully bigger, and that adds up on mobile where JS parse time actually shows up in your Core Web Vitals.<\/p>\n Everyone brings up bundle size and boilerplate. Fine, those matter. But the win I keep noticing is more subtle.<\/p>\n The win is colocation. Zustand stores don’t need to live in a top-level store file. I’ve started putting feature-scoped stores in the feature folder next to the components that use them:<\/p>\n That colocation is quietly wonderful. When we deleted the billing feature six months later, the store went with it. No dead code in a central You can do this with RTK if you’re disciplined, but the library’s shape actively pushes you toward a central store. Zustand’s shape pushes you toward the store belonging to whatever needs it.<\/p>\n The other quiet win is async. No thunks, no sagas, no listener middleware. If you want a fetch inside an action, write a fetch:<\/p>\n This is one of those things that sounds like a small thing until you’ve written your fifth I wrote about a related shift in React Query vs SWR<\/a> \u2014 server state is a different animal from UI state, and once you separate those in your head, the “state management” question gets much smaller.<\/p>\n This is the section where I stop being a Zustand cheerleader.<\/p>\n Time-travel DevTools are still the gold standard. Zustand has DevTools middleware and it works, but Redux DevTools with full action history is a different tier of debugging. On a support bot I was building last year, I could replay the last twenty user actions and see exactly where a state transition went sideways. That doesn’t work as cleanly in Zustand, and if your app has a truly complex reducer graph, you’ll miss it.<\/p>\n RTK Query is a real feature. If you’re going all-in on Redux for both UI and server state, RTK Query gives you caching, deduplication, and normalized results without adding another dependency. Zustand doesn’t try to do server state. You’d pair it with TanStack Query, which is fine, but that’s two libraries instead of one.<\/p>\n Bigger teams also appreciate the guardrails. Redux’s whole idea, that actions are the only way state changes and every action is traceable, is more useful the more people are touching the code. On a team of two, “here’s a hook, call the function” is fine. On a team of twelve rotating between features, “every state change is a named, typed action that shows up in DevTools” starts earning its keep.<\/p>\ncreateSlice<\/code> fixed the most painful boilerplate, RTK Query is genuinely great for server state, and the DevTools are still the gold standard for time-travel debugging. If you’re building anything with a large team and a long tail of features, RTK is a defensible pick.<\/p>\ncreateSlice<\/code>, you’re still writing a Provider, a store file, typed hooks, and a slice per feature. For a modal-toggle-and-a-user-object app, that’s a lot of ceremony. The old-way version, before I got tired of it, looked like this:<\/p>\n\/\/ store\/uiSlice.ts\nimport { createSlice, PayloadAction } from '@reduxjs\/toolkit'\n\nconst uiSlice = createSlice({\n name: 'ui',\n initialState: { isSidebarOpen: false, theme: 'light' as 'light' | 'dark' },\n reducers: {\n toggleSidebar: (state) => { state.isSidebarOpen = !state.isSidebarOpen },\n setTheme: (state, action: PayloadAction<'light' | 'dark'>) => {\n state.theme = action.payload\n },\n },\n})\n\nexport const { toggleSidebar, setTheme } = uiSlice.actions\nexport default uiSlice.reducer\n\n\/\/ store\/index.ts\nimport { configureStore } from '@reduxjs\/toolkit'\nimport ui from '.\/uiSlice'\nimport { useDispatch, useSelector, TypedUseSelectorHook } from 'react-redux'\n\nexport const store = configureStore({ reducer: { ui } })\nexport type RootState = ReturnType<typeof store.getState>\nexport type AppDispatch = typeof store.dispatch\nexport const useAppDispatch: () => AppDispatch = useDispatch\nexport const useAppSelector: TypedUseSelectorHook<RootState> = useSelector\n<\/code><\/pre>\n<Provider store={store}><\/code> in your root, and every component doing const dispatch = useAppDispatch(); dispatch(toggleSidebar())<\/code> to flip a boolean.<\/p>\nZustand’s whole thing in about eight lines<\/h2>\n
\/\/ store\/ui.ts\nimport { create } from 'zustand'\n\ntype UIState = {\n isSidebarOpen: boolean\n theme: 'light' | 'dark'\n toggleSidebar: () => void\n setTheme: (t: 'light' | 'dark') => void\n}\n\nexport const useUI = create<UIState>((set) => ({\n isSidebarOpen: false,\n theme: 'light',\n toggleSidebar: () => set((s) => ({ isSidebarOpen: !s.isSidebarOpen })),\n setTheme: (theme) => set({ theme }),\n}))\n<\/code><\/pre>\nconst isSidebarOpen = useUI((s) => s.isSidebarOpen)\nconst toggleSidebar = useUI((s) => s.toggleSidebar)\n<\/code><\/pre>\nuseMemo<\/code> or React.memo<\/code>. Read the Zustand docs on selectors<\/a> once and you’ll internalize the pattern in about ten minutes.<\/p>\nWhere Zustand actually wins (and it’s not what people say)<\/h2>\n
features\/\n billing\/\n BillingTable.tsx\n useBillingStore.ts <-- lives here, not in \/store\n edit-modal\/\n<\/code><\/pre>\nrootReducer<\/code>. No orphaned selectors. It just disappeared with the folder.<\/p>\nexport const useBilling = create<BillingState>((set) => ({\n invoices: [],\n loading: false,\n fetchInvoices: async () => {\n set({ loading: true })\n const res = await fetch('\/api\/invoices').then((r) => r.json())\n set({ invoices: res, loading: false })\n },\n}))\n<\/code><\/pre>\ncreateAsyncThunk<\/code> with three lifecycle actions and realized you were basically hand-rolling useState<\/code> with extra steps.<\/p>\nWhere Redux Toolkit still wins<\/h2>\n