If you’re building React apps, chances are you’ve either used Redux or Zustand for state management.
All solid choices for managing state in your React app. But when your app grows, when thousands of updates happen under the hood, and when users expect a smooth UI, does your state manager keep up?
And for this test, we are also including a new library. That we built ourselves.
Overwatch, a lightweight, hooks and minimal API based state management library for React and Next.js with a single focus.
Keep your apps fast while making state management feel effortless.
and are these popular libraries really the best for your app’s performance?
🕵🏻‍♂️ We decided to find out.
⚡️ But How Fast Is “Fast”?
Anyone can claim “fast”, so I decided to put Redux, Zustand, and Overwatch Ts to the test under realistic conditions.
🤔 How I Tested?
In this benchmark I used the best practices for all three libraries, no additional optimisations.
I ran benchmark tests that simulate real world usage patterns:
- 10,000 concurrent state updates to stress test update cycles.
- 1000 Components to test re-rendering using specialised Hooks provided by all three. (useStore, usePicker and useSelector)
- Cold start initialization to measure startup overhead.
- Memory usage deltas before and after updates.
- Multiple iterations (100 runs) to get consistent averages.
All libraries were tested under the same machine and conditions for fairness.
đź“Š The results?
🚀 Overwatch clocked in ~11.7× faster than Zustand (~91% faster).
🚀 Overwatch was ~18.3× faster than Redux Toolkit (~95% faster).
We were as surprised as you are.
⚡️ Why Is Overwatch TS So Fast?
While Zustand and Redux use well-optimized approaches, Overwatch TS achieves these gains by:
As one of the Overwatch developers, I believe it takes a fresh approach from an architectural perspective. It moves away from the Flux Architecture (like Zustand/Redux) and uses a modern, singleton Publisher-Subscriber pattern. Its simplicity is its core strength. Yes, there are other major factors as well.
âś… Using microtask-based batching to combine multiple state updates in the same tick, reducing re-render cycles.
âś… Employing immutability safely and efficiently, skipping heavy proxies where not needed.
âś… Performing fine-grained subscriptions so only the components that need updates are re-rendered.
âś… Removing boilerplate without sacrificing control.
This means your React components stay fast, even with heavy interactions and complex states.
🤝 Want to See for Yourself?
I’ve made it super easy,
👉🏻 Run the live benchmarks yourself: Watchly Benchmark
</> Inspect or fork the benchmarking playground: Github
✨ Contribute to GitHub:
đź”— Check out Overwatch TS on GitHub
đź”— Documentation
Help Build the Sensible
I truly believe we’re past the age of monolithic, store-centric global state. Modern applications are more component-driven, async-heavy, and UI-dynamic than ever. We need tools that reflect this reality.
Join the journey to build a most sensible state layer for React.
Let me know in the comments, or feel free to reach out if you’d like help optimizing your app’s performance.
Top comments (2)
Looks interesting, however I do have some concerns about this library, especially regarding Typescript. The library does not provide any type safety, the user has to provide types every time he uses the hook (and he can provide wrong types):
Which means I can easily end up in a situation like this:
Same goes for picker:
Type safety is a must for state management libraries, this will break at first refactor you do
Hi Oleksandr,
Really appreciate your feedback, and I completely agree with your concern. We’re aware that while the library does have TypeScript support, there are still some gaps. My team and I are actively working on making it fully TypeScript-friendly. Feedback like yours is exactly what helps us improve, so thank you for taking the time to share it.
It’s open source! If you ever want to contribute, your help is much appreciated.