Jotai advantages over Recoil

[NavidGhobadi]

I have recently gotten familiar with Jotai and still searching for a concrete list of Jotai advantages over Recoil.
somehow wondering why there should be Jotai state manager with absolutely similar approach to Recoil. I'm sure maintainers are doing their best to improve the library more and more, but I wan't to get some idea about current and future of the library

[dai-shi]

This is a tricky question. It might be good to continue discussion instead of just answering once. I hope other people to jump in and have questions and answers.

For now, I have one technical aspect for an answer. Recoil atoms are distinguished by string keys and jotai atoms are by object references. Jotai's implementation is based on WeakMap, and data is garbage collected by JS engine. This simplifies the implementation quite a bit. This will be a difference that lasts for a long time, maybe forever.

https://twitter.com/dai_shi/status/1380885195549597696

[sandren]

A few advantages of Jotai over Recoil off the top of my head:

• Jotai has a smaller core API
• Jotai has a less boilerplate code (no string keys!)
• Jotai has a 90% smaller bundle size and is getting smaller over time (Recoil for comparison)
• Jotai has a variety of official integrations for managing pieces of state with extra functionality (immer, optics, react-query, xstate, valtio, zustand, redux, etc) and I'm sure more will be added over time
• Jotai has built-in persistence
• Jotai has a nicer website and mascot 😉

There is also an article on the topic with more information.

[Thisen]

I believe one of the major differences, besides all the previous mentioned, is that Jotai is TypeScript focused and there's a focus on delivering good DX in a TypeScript environment.

[andrewagain]

I haven't tried Jotai yet - but just been pretty heavily burned by Recoil. Recoil essentially holds on to every piece of state it is ever given. See these GitHub issues about memory leaks: facebookexperimental/Recoil#1064 facebookexperimental/Recoil#1040 facebookexperimental/Recoil#981 facebookexperimental/Recoil#954

I'm enticed by Jotai's garbage collection and I'm looking to convert my Recoil project to Jotai now.

UPDATE: I finished migrating from Recoil to Jotai. My app was leaking megs of memory every minute with Recoil, but with Jotai it is leak-free 😀 - thank you Jotai maintainers!

[dai-shi]

https://twitter.com/dai_shi/status/1423486220596699142

1. It's easier to learn because of the minimalistic API (only two basic APIs, no string keys)
2. It covers various use cases because of integrations like React Query, XState.
3. It's good for library use because atom scope allows to separate jotai in lib and jotai in app.

[AjaxSolutions]

Jotai performance is a lot better compared to Recoil.

https://twitter.com/dai_shi/status/1480083292884172801

[quangbuule]

I switched to Jotai (from Recoil) for just 1 reason:

Recoil has useRecoilValue and useRecoilState which can make devs hiccup whenever they need to use an atom, it's hard to have a defined convention regarding this in the project. With Jotai, it's useAtom only (other utils like useAtomValue or useUpdateAtom don't belong to core API - which I am not sure will be using).

Other things like @dai-shi mentioned are like bonuses to me, they weren't the reason that I switched. Well done team!

[dai-shi]

Hi, thanks for the feedback.

Note that in #885, we plan to add useAtomValue and useSetAtom in the core API. This is mainly due to the library implementation perspective. From the usage perspective, we still recommend to use useAtom for the first choice. Our "basic" core api is atom and useAtom. Other three are "additional" core api. We should make this clear in docs and distinguish them. cc @Thisen

[nexttrack07]

I wanted to mention another MAJOR difference that is not on this list. Jotai supports "write-only" atoms whereas in Recoil, a selector needs to have both "get" and "set". This is a pretty big consideration for me to switch to Jotai. In Jotai, the "newValue" you pass to a write-only atom can be ANYTHING whereas in Recoil, the newValue you pass to the "set" portion of a selector has to be exact shape as the return value of the "get" portion! This is a huge restriction IMO...

[dai-shi]

Thanks! Yeah, that's true. I wasn't probably aware of this fact when I wrote the first answer.

[ShravanSunder]

I'm not certain this is a pro or a con per say. In some ways this determinism is preferable, nothing wrong with strongly typed atoms.

[nexttrack07]

In a complex app, there will be several scenarios where you need to modify several atoms at once without caring about their current values. For example, in a drawing app imagine you want to select a few shapes and align them to the middle of canvas. You don't care about their existing locations.

For those type of scenarios, which my app has a lot of, Jotai is awesome. The alternative is to use useRecoilCallback in Recoil which doesn't even have a getter :(

[Kay2dan]

Im new to Jotai but 1 thing I miss from Recoil:

• useSetAtom only accepts values. Recoil useSetRecoilState accepts both values & an update func, ala React state setter func. This helps immensely with components which donot need to subscribe the change in value of an atom & only act as setters.

Sorry, I stand corrected. It DOES support update func.

[nexttrack07]

Umm... pretty sure it accepts setter functions. Not sure if I'm misunderstanding your point.

[dai-shi]

@Kay2dan It just depends on how you define the write function of your atom you are using for useSetAtom. Jotai takes different design decision from Recoil.

[Kay2dan]

Thank you for the clarafication!

[Cpt-Falcon]

Another big advantage--the recoil repository is basically dead while this repo seems like it has a flourishing community. It looks like all of the FB devs who worked on recoil got fired.

[Qquanwei]

I switched from recoil to jotai. There are some scenarios that jotai seems difficult to implement,

such as

1. I want to refresh atom. There is useRecoilRefresher in recoil, but jotai does not have a good method and needs to be implemented by myself, and it does not seem to be very elegant.

jotai refresher

import { atom, Getter } from 'jotai'

export function atomWithRefresh<T>(fn: (get: Getter) => T) {
  const refreshCounter = atom(0)

  return atom(
    (get) => {
      get(refreshCounter)
      return fn(get)
    },
    (_, set) => set(refreshCounter, (i) => i + 1),
  )
}

This way of writing is not suitable for progressive development. I will define a simple atom at the beginning. When I find that it needs to be refreshed, I will rewrite my atom definition. (Especially when modifying old code, we cannot well evaluate whether the two definitions are completely equivalent). Compared with recoil, I prefer the experience of recoil.

2. recoil can define asynchronous default values, which is useful when rendering asynchronous data.

in Recoil

const valueWithDefaultRemoteValue = atom({
  key: 'some key',
  default: selector({
    key: 'some key default',
    get: () => fetch('/api')
  })
})

It would be very useful if this scenario could be supported, but jotai still needs to use some strange writing methods to achieve this function.

in jotai

const defaultValueAtom = atom(async () => {
  return await fetch('/api');
})

const rawValueAtom = atom(undefined);
const valueAtom = atom((get) => {
  return get(rawValueAtom) || get(defaultValueAtom);
}, (_, set, data) => {
  set(rawValueAtom, data);
})

Although I can repackage it into a utility function, I need to implement this method separately in many projects. Maybe someone will implement a similar function but with a different name. In short, due to the lack of functionality, a large number of dialects will appear in jotai. Different jotai project have different usage habits, which makes maintenance difficult.

[dai-shi]

Different jotai project have different usage habits, which makes maintenance difficult.

That's actually expected and small Jotai core allows to be more maintainable. So, it's a different design policy.

That said:

1: We can consider implementing atomWithRefresh in jotai/utils, if that's a community expectation, which seems to be so.

2: Does atomWithDefault help?

[Qquanwei]

atomWithDefault is what I want, there are more tools provided in utils than I thought, I think I should re-evaluate the use of jotai.

I'm also looking forward to an official implementation for atomWithRefresh.

Thank you for your work

[dai-shi]

#2379

[AjaxSolutions]

The last Recoil release was in April 2023. There are some questions if this library is still being maintained.

[Qquanwei]

recoil is currently in an unmaintained stage.