How is jotai different from zustand?

[dai-shi]

Name

Jotai means "state" in Japanese.
Zustand means "state" in German.

Analogy

Jotai is close to Recoil.
Zustand is close to Redux.

Where state resides

Jotai state is within React component tree.
Zustand state is in the store outside React.

How to structure state

Jotai state consists of atoms (i.e. bottom-up).
Zustand state is one object (i.e. top-down).

Technical difference

The major difference is the state model. Zustand is basically a single store (you could create multiple stores, but they are separated.) Jotai is primitive atoms and composing them. In this sense, it's the matter of programming mental model.

Jotai can be seen as a replacement for useState+useContext. Instead of creating multiple contexts, atoms share one big context.

Zustand is an external store and the hook is to connect the external world to the React world.

When to use which

• If you need a replacement for useState+useContext, jotai fits well.
• If you want to update state outside React, zustand works better.
• If code splitting is important, jotai should perform well.
• If you prefer Redux devtools, zustand is good to go.
• If you want to make use of Suspense, jotai is the one.
• If you need a global store to bridge between two react renderers, zustand will only work. (no longer valid with jotai's provider-less mode, but zustand may work better.)

[Drakota]

Jotai looks fun to play with, thank you!

I've just realized that Zustand and Jotai were made by you guys @ react-spring, this brings the question, what kind of problems have you run into that justified the development of two different (and possibly concurrent) state management libraries? Is there any concerns of one library being cannibalized by the other one or splitting efforts?

[dai-shi]

While we were discussing about improving Zustand, we had two major points that we can't implement in Zustand. The first is that Zustand is an external store by design. We want a lib that only store states internally in React, which we believe supports CM better. The second is atom model that is often requested in some Zustand issues. We can't simply add the different concept into Zustand without influencing the feature complete API. So, we decided to release another lib from the same org. Each has different goal and concept. Both are more or less unopinionated and let users choose.

[sonatard]

Thanks for awesome library!!

The first is that Zustand is an external store by design. We want a lib that only store states internally in React.

What does it mean that ”extenal store” and ”store states internally in React ”?

[dai-shi]

@sonatard "Internal state" means React.useState, everything else is basically external (from the React point of view). Usually, we create a store object and put state in it, so I called "external store."

[merisbahti]

I was curious about the statement:

Jotai state is within React component tree.

So I made a lib which looks/feels like jotai/recoil but the atoms are outside the tree:

https://github.com/merisbahti/klyva

Take a look at the tests:
https://github.com/merisbahti/klyva/blob/master/test/atom.test.ts

The atom exposes two functions: write and subscribe, so it’s pretty trivial to make a useAtom from that.

But also, for fun, I exposed a function focus, which is an addition to jotai which lets you use optics to ”slice” an atom.
(Examples here: https://github.com/merisbahti/klyva/blob/master/test/atom-perf.test.ts)

Thanks again for this library, it’s very inspiring.

ps. useAtom would look like this:

const useAtom = <T>(atom: Atom<T>) => {
  const [value, setValue] = React.useState(atom.getValue())
  React.useEffect(() => atom.subscribe(setValue), [atom])
  return [atom.getValue, atom.update]
}

[dai-shi]

@merisbahti Hi! Glad to see you got inspired and created something.
Yeah, it's an important distinction for me. We believe that having state in React as single source of truth can give more benefit in CM. But, I can't easily convince someone about it: a) CM is not yet ready and we don't know what it's like when it lands, b) the benefit can be trivial for most apps.
Jotai is the same as Recoil, in this sense, trying to be in React state.
Having state in external store outside React is also useful in certain cases. We have zustand for such use cases. It is technically possible (and rather easy) to add atom model in zustand, but currently we don't have such a plan.

btw, you might be interested in this issue and the discussion: #44

[merisbahti]

aah I was wondering why that was the case, I see, well then that explains it for me! thanks!

btw I'm the author for that linked issue ;)

[dai-shi]

aaah, what a shame. didn't pay much attention. (I remember your profile picture, thought it's on Twitter, looked for it...)

[ozio]

I need the same article, but for Recoil.

[dai-shi]

You mean the comparison between Jotai and Recoil?

[ozio]

You mean the comparison between Jotai and Recoil?

Yup.

I saw small explanation in the README.md, but it's too short to decide. For me it sounds like "we don't use strings as a keys - that's the main reason to use Jotai". In the other words, if I'll make a simple wrapper for Recoil to exclude string keys - what's the difference will be then?

[dai-shi]

Alright. First off, I'm familiar with Jotai and Zustand about their implementations, the backgrounds and goals. However, I'm not familiar with Recoil implementation at all. I grasp the Recoil docs, but don't understand it fully. Hence, it's pretty biased and maybe not accurate. Having that said, yes the biggest difference is no string keys. Recoil has it by design to allow serialization easily. Jotai avoid the string keys to simplify the API for use cases without serialization, and serialization is left for developers (we are trying to come up with best practice about serialization.) The API design is also different. While Recoil provides various functions to fulfill their requirements, Jotai's focus is to provide primitive APIs, and everything else is built on it. This will help learning the APIs in a leaner way, and creating another function based on primitives (encouraging ecosystem). The implementation should be very different, but let's not go in deep this time.

Here's the summary.

---

How is jotai different from recoil?

Developer

• Jotai is developed with collective work by a few developers in Poimandres (formerly react-spring) org.
• Recoil is developed by a team at Facebook.

Basis

• Jotai is focusing on primitive APIs for lean learning, and it's unopinionated. (The same philosophy with Zustand)
• Recoil is full featured for big apps with various requirements.

Technical difference

• Jotai depends on atom object referential identities.
• Recoil depends on atom string keys.

When to use which

• If you want to learn something new, either should work.
• If you want a Facebook product, choose Recoil obviously.
• If you like Zustand, Jotai would also be pleasant.
• If your app heavily requires state serialization (storing state in storage, server, or URL), Recoil comes with good features.
• If you need React Context alternatives, Jotai comes with enough features.
• If you would try to create a new library, Jotai might give good primitives.
• Otherwise, both are pretty similar about the general goals and basic techniques, so please try both and give us a feedback.

[fjcalzado]

This kind of comparisons are great @dai-shi, I would add them to front page documentation.