State Management at Scale with Daishi Kato (Author of Zustand)

🎧 New Señors @ Scale Episode

This week, I spoke with Daishi Kato, the author and maintainer of Zustand, Jotai, and Valtio — three of the most widely used state management libraries in modern React.

Daishi has been building modern open source tools for nearly a decade, balancing simplicity with scalability. He's also behind Waku, a framework built around React Server Components, pushing the boundaries of how we structure and ship React apps.

In this episode, we dive deep into the philosophy behind each library, how they differ from Redux and MobX, the evolution of the atom concept, and how Daishi manages the mental load of maintaining four popular open source projects.

⚙️ Main Takeaways

1. Zustand, Jotai, and Valtio share a goal but take different approaches

All three libraries share the same goal: preventing extra re-renders. But they take fundamentally different approaches to structuring and managing state.

• Zustand (pronounced "Zastan"): A global store, like a global variable. It uses a single global store similar to Redux, but philosophically different because Redux is based on reducers — Zustand is not.
• Jotai (pronounced "Jyotai"): A set of atom definitions, which Daishi describes as "just functions." Instead of a single store, Jotai is a set of functions that define state.
• Valtio (pronounced "Varsho"): Just JavaScript objects. It's fundamentally based on using JavaScript objects with proxy-based reactivity.

2. Zustand was born from React Hooks excitement

When Daishi saw the announcement of React Hooks, he got excited and started developing a bunch of React-focused libraries. He picked global state as the field to explore because he wasn't good at components and styling — he preferred working on logic rather than "look and feel."

• The beginning: Daishi developed several related libraries to address global state, including React context.
• The motivation: Global state is more like logic, which was a great fit for his interests and skills.

3. Jotai evolved from avoiding proxies and selectors

Jotai's atom concept evolved from Daishi's exploration with React context using useReducer or useState. His initial approach used JavaScript proxies, but he realized that proxies weren't welcomed by everyone.

• The problem: Daishi wanted to avoid the usage of selectors (popular with Redux and Zustand) for the goal of render optimization.
• The solution: When Facebook announced Recoil, Daishi learned the API but wanted something different. Jotai allows render optimization without selectors and without proxies.
• The model: Jotai is more like useState and is more appropriate for concurrent rendering, which was not technically possible in Zustand.

4. Valtio embraced proxies when they became acceptable

After releasing Zustand and Jotai, Daishi had an idea to use proxies again. But this time, the approach was different.

• The shift: At the time Valtio was created, proxies were recognized and acceptable in the community. Instead of hiding proxies as an implementation detail, Valtio explicitly says "this is a proxy."
• The difference from MobX: Valtio's key differentiator is its hook-based API. MobX uses the observer pattern, but Valtio provides a hook-based API, which was an opportunity Daishi saw after discussions with the MobX team about providing Hooks API didn't materialize.
• When not to use it: If people don't like proxies, Valtio isn't a good fit. Since proxies are now shown (not hidden), developers need to understand they're using proxies.

5. Waku started as an experiment with React Server Components

After releasing the three state management libraries, they were mostly stable. Daishi wanted to do something new and decided to tackle the React Server Components space.

• The motivation: Daishi wanted to learn how state management libraries can play with React Server Components and needed to understand how React Server Components work.
• The evolution: It started as a personal project and playground. Eventually, someone said it was going to be interesting, so Daishi decided to make it his fourth project to focus on.
• Best suited for: Small to medium-sized web applications, or static sites. It's easier to understand building static sites using React Server Components.

6. Managing four libraries requires prioritization

Daishi is currently focusing on Waku, while the other three are more stable. He doesn't spend much time exploring something new in the state management libraries, but he still maintains them and is happy to add more features.

• The strategy: Prioritize and work on them, but focus on Waku right now.
• The challenge: The mental load is challenging, but focusing on one project while keeping others stable helps manage it.

7. Zustand rejects everything to stay minimal

When it comes to feature requests, Zustand has a simple policy: reject everything.

• The principle: Zustand is trying to be small and minimal. That's the whole point of the library.
• The extension system: The middleware system in Zustand is powerful (maybe too powerful), which allows extending capabilities without bloating the core.
• The balance: The minimal core is what matters most, but people want more features, so an extendable system is a necessity.

8. Zustand doesn't use React Context — and that's intentional

Zustand completely ignores React Context, which was a deliberate design decision.

• The misconception: Many people think global state requires React Context, but if you have a store outside React, you don't need useState and you don't need Context.
• The story: Before Zustand, Daishi made a small library that used a store outside React and subscribed directly to it. A user gave feedback saying it's best practice to use React Context. Daishi changed it to use Context, but it was still using the external store. After that, he realized it wasn't a necessity.
• The pioneer: Zustand was a pioneer in showing the usage of not using React Context and using a global external store instead.

9. useSyncExternalStore made Zustand even smaller

React 18's useSyncExternalStore was a game-changer for Zustand.

• Before React 18: Zustand was trying to do what useSyncExternalStore does in a user-land way. The biggest contribution was providing the subscription mechanism with useEffect.
• After React 18: Zustand's implementation now just uses useSyncExternalStore. It's even smaller — just a few lines of code in terms of subscribing to the store using the hook.
• The irony: The contribution from React was so great that it almost makes Zustand unnecessary, but the library still provides value through its API and ecosystem.

10. Jotai is the best fit for Waku

If Daishi had to implement state in Waku, he would use Jotai.

• The reason: The other two (Zustand and Valtio) are stores. Jotai is like an abstraction of state, which means you can use the same abstraction on the client and on the server.
• The fit: This makes Jotai well-suited for React Server Components, where you need state that works on both client and server.

🧠 What I Learned

• Zustand, Jotai, and Valtio all prevent extra re-renders but use completely different mental models.
• Zustand's philosophy is "reject everything" to stay minimal, but the middleware system allows powerful extensions.
• Jotai evolved from wanting render optimization without selectors and without proxies.
• Valtio embraced proxies when they became acceptable, differentiating itself with a hook-based API vs. MobX's observer pattern.
• Waku started as an experiment to learn React Server Components and understand how state management works with them.
• Zustand doesn't use React Context because it stores state outside React — this was a deliberate design decision.
• useSyncExternalStore made Zustand even smaller, reducing it to just a few lines of code.
• Managing multiple open source libraries requires prioritization — focus on one while keeping others stable.
• The hardest part of rejecting feature requests is being polite to first-time contributors without discouraging them.
• AI coding assistants make it harder to tell if a PR is from a beginner or experienced contributor.
• Daishi prefers a competitive community over React having built-in state management.
• Documentation contributions are often more valuable than code contributions for open source success.
• Jotai is best suited for Waku because it's an abstraction that works on both client and server.

💬 Favorite Quotes

"Zastan is more like a global store, a global variable. And Jota is like defining functions to define state. And Valercio is like just JavaScript objects."
"I wasn't good at doing components and styling and all that stuff. I would like to do something off look and feel. So global state is more like logic."
"Redux is basically reducers. Zastan is not, so it's pretty different in that sense."
"Jotai allows render optimization without selectors without proxies."
"Proxies are now shown. It's not hidden, meaning the developers has to have to understand they are using proxies."
"Zustand is trying to be small and minimal. Basically, we do not accept any new features. So we reject everything."
"Zustand was a pioneer to show the usage of not using React Context and it uses the global external store."
"useSyncExternalStore is provided by React. The stand implementation is just using useSyncExternalStore. So it's a great contribution from the library."
"I wanted to create something. Yeah, I do contribute to other projects, but my focus is creating something my own."
"Jota is like an abstraction of state, which means we can use the same abstraction on the client, on the server."

🎯 Also in this Episode

• How to pronounce Zustand, Jotai, and Valtio (Zastan, Jyotai, Varsho)
• Why Daishi picked global state as his field to explore
• The story behind Jotai's evolution from proxy-based to atom-based
• How Valtio compares to MobX in terms of developer experience
• When not to use Valtio (if you don't like proxies)
• What kind of applications Waku is best suited for
• How Waku will coexist with Next.js (not trying to beat it)
• How creating Waku changed Daishi's thinking about client-side state
• The hardest decision about rejecting feature requests (being polite to first-time contributors)
• Whether React should have built-in state management (Daishi prefers competitive community)
• Daishi's favorite community contribution (documentation improvements)
• How to decide when a problem deserves a new library vs. improving an existing one
• Zustand's design principles (minimal core, powerful middleware)
• Why Zustand ignores React Context
• Trade-offs between Jotai and Zustand in real-world apps
• How Zustand maintains consistency across community packages
• Whether Daishi plans to unify concepts between libraries (no, they serve different purposes)
• Future plans: focusing on Waku v1 alpha, then building libraries on top of it
• Book recommendation: SICP (Structure and Interpretation of Computer Programs)

Resources

More from Daishi:
Zustand on GitHub
Jotai on GitHub
Valtio on GitHub
Waku on GitHub
pmndrs GitHub Organization
Daishi's GitHub

Book Recommendation:
SICP: Structure and Interpretation of Computer Programs

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 35 minutes on state management, React libraries, and the philosophy behind building tools that balance simplicity with scalability.

If you're managing global state in React, interested in the internals of popular open-source tools, or curious about the future with React Server Components, this episode is a must-listen.

Happy building,
Dan