Recoil vs Jotai: Facebook Atoms vs Minimal Atomic State

Overview

Recoil and Jotai both implement the atomic state management pattern for React — the idea that global state is composed of small, independent units (atoms) that components can subscribe to individually, enabling fine-grained re-rendering. Recoil was created at Facebook (now Meta) and introduced the atom/selector vocabulary to the React ecosystem. Jotai was created by Daishi Kato (who also built Zustand and Valtio) as a minimal, distilled take on the same atomic model, addressing what Jotai's author saw as unnecessary complexity in Recoil.

Both libraries integrate deeply with React's concurrent features, supporting Suspense for async atoms. The key differences are in API surface area, bundle size, and the approach to atom identity — Recoil requires a unique string key for every atom while Jotai uses JavaScript object identity.

Key Technical Differences

Recoil atoms are defined with a key (a string that must be globally unique within the application) and a default value. The key requirement causes two practical pain points: key collision bugs when atoms are defined in different files, and serialization challenges in SSR scenarios where atom state must be hydrated per-request. Recoil's atom effects are a powerful feature for synchronizing atoms with external systems — reading from and writing to localStorage, URLs, or external reactive stores.

Jotai atoms are plain JavaScript objects — atom identity is their object reference. No keys, no key collisions, no serialization concerns around string identifiers. A Jotai atom is created with atom(initialValue) and used in any component with useAtom(myAtom). Derived atoms are created by passing a read function to atom(). The simplicity is deliberate and meaningful: there are fewer concepts to learn and fewer failure modes.

Recoil's selectors are declarative derived values that can be synchronous or asynchronous. An async selector can fetch data and return a Promise; Recoil integrates this with React Suspense so components automatically show a loading state. Jotai handles the same use case with async atoms — atoms whose initial value or read function returns a Promise — which also integrate with Suspense.

Performance & Scale

Both libraries achieve fine-grained subscriptions: components only re-render when the specific atoms they use change. This is their shared architectural advantage over context-based state. Jotai's smaller bundle size (3KB vs Recoil's 21KB) matters for applications sensitive to initial load time. Both libraries support React concurrent features including Suspense and transitions, enabling smooth async UX.

When to Choose Each

Choose Recoil for applications that need atom effects for external synchronization or complex async selector graphs. Recoil's more explicit model with string keys is also arguably easier to debug when something goes wrong — you can identify atoms by their key names.

Choose Jotai for most new applications where simplicity and minimal bundle size are valued. The lack of required keys, the minimal API, and the active maintenance from a prolific open-source author make Jotai the more pragmatic choice for teams evaluating atomic state management.

Bottom Line

Jotai wins on simplicity, bundle size, and API elegance for most use cases. Recoil wins for complex async state graphs and teams already familiar with the Recoil ecosystem. Given Meta's slower development pace on Recoil, Jotai is also the safer long-term bet for new projects.