Recoil vs Jotai vs Zustand: State Management Entscheidungsmatrix

1. Warum diese drei Bibliotheken zusammen betrachtet werden

Recoil, Jotai und Zustand lösen alle dasselbe Grundproblem: React State über Komponentengrenzen hinweg teilen, ohne die Schwerfälligkeit von klassischem Redux. Alle drei sind deutlich kleiner als Redux Toolkit, verzichten auf Reducer Boilerplate und lassen sich in wenigen Minuten in ein bestehendes Projekt integrieren. Trotzdem unterscheiden sie sich fundamental in ihrem mentalen Modell, und genau diese Unterscheidung entscheidet in der Praxis, welche Bibliothek zu einem konkreten Projekt passt.

Recoil und Jotai gehören zur Familie der atom basierten State Management Ansätze: Zustand wird in vielen kleinen, unabhängigen Einheiten gehalten, die einzeln abonniert werden können. Zustand hingegen folgt dem klassischeren Modell eines zentralen Stores mit einem einzigen Hook Zugriff, ähnlich wie eine schlanke Version von Redux ohne Reducer Pattern. Wer verstehen will, wann welches Modell im eigenen Projekt Sinn ergibt, muss zuerst die strukturellen Unterschiede zwischen Atoms und einem zentralen Store verstehen.

2. Grundmodell: Atoms versus zentraler Store

Ein Atom bei Recoil oder Jotai ist eine einzelne, unabhängige Zustandseinheit, vergleichbar mit einer globalen Version von useState. Komponenten abonnieren nur die Atoms, die sie tatsächlich lesen, wodurch Rerenders automatisch auf die betroffenen Komponenten beschränkt bleiben, ohne dass manuell mit Selektoren optimiert werden muss. Bei Zustand liegt der gesamte relevante State dagegen in einem einzigen Store Objekt, und die Feingranularität der Rerenders hängt davon ab, wie präzise Komponenten mit Selektor Funktionen auf einzelne Felder zugreifen.

Dieser Unterschied hat direkte Konsequenzen für die Architektur größerer Anwendungen. Mit Atoms lässt sich State organisch pro Feature erweitern, jedes neue Atom ist unabhängig und muss nicht in ein zentrales Store Objekt eingepflegt werden. Mit einem zentralen Store bei Zustand bleibt dagegen der gesamte State an einer Stelle sichtbar, was das Debugging und das Verständnis der Gesamtarchitektur erleichtert, aber bei sehr großen Anwendungen zu einem wachsenden, unübersichtlichen Store Objekt führen kann, wenn nicht bewusst in mehrere Stores aufgeteilt wird.

// Recoil atom model — each atom is an independent unit of state
import { atom, useRecoilState } from 'recoil';

const themeState = atom({
  key: 'themeState',
  default: 'light',
});

function ThemeToggle() {
  const [theme, setTheme] = useRecoilState(themeState);
  return (
    <button onClick={() => setTheme((t) => (t === 'light' ? 'dark' : 'light'))}>
      Current theme: {theme}
    </button>
  );
}

3. Bundle Size und Rerender Verhalten

Bundle Size ist bei State Management Bibliotheken selten das entscheidende Kriterium, spielt aber bei Anwendungen mit strikten Performance Budgets eine Rolle. Zustand ist mit rund einem Kilobyte gzip die kleinste der drei Bibliotheken und hat außer React selbst keine zusätzlichen Peer Dependencies. Jotai liegt in einer ähnlichen Größenordnung, während Recoil deutlich größer ausfällt und zusätzlich einen eigenen Context Provider sowie interne Scheduler Logik mitbringt, die den Bundle spürbar vergrößern.

Beim Rerender Verhalten unterscheiden sich alle drei durch ihre granulare Subscription Logik deutlich von Context basiertem State, bei dem jede Änderung potenziell alle Consumer neu rendert. Jotai und Recoil erreichen feingranulare Updates durch das Atom Modell selbst, Zustand erreicht dasselbe Ergebnis durch Selektor Funktionen, die beim Store Zugriff übergeben werden. In Benchmarks mit vielen unabhängigen State Slices zeigt sich, dass Jotai durch seinen minimalen internen Overhead häufig die schnellsten Ergebnisse liefert, während Recoil durch seine zusätzliche Buchhaltung für Zeitreise Debugging etwas mehr Overhead pro Atom Update hat.

4. Recoil im Detail: Atoms, Selectors und Wartungsstatus

Recoil wurde von einem Meta Team entwickelt und war die erste populäre Bibliothek, die Atoms als React natives Konzept in den Mainstream brachte. Neben einfachen Atoms bietet Recoil Selectors, mit denen sich abgeleiteter State deklarativ aus einem oder mehreren Atoms berechnen lässt, inklusive automatischer Memoization und optionaler asynchroner Berechnung direkt im Selector selbst. Das macht Recoil besonders mächtig für Anwendungen mit vielen voneinander abhängigen Ableitungen.

Der entscheidende Nachteil von Recoil im Jahr 2026 ist der Wartungsstatus: Die Entwicklung ist deutlich verlangsamt, größere Releases sind selten geworden, und viele Teams, die früher auf Recoil gesetzt haben, migrieren aktiv zu Jotai, das von denselben Grundideen inspiriert ist, aber aktiver gepflegt wird und eine kleinere, stabilere API bietet. Für neue Projekte ist Recoil daher nur noch in Ausnahmefällen empfehlenswert, etwa wenn bereits umfangreiche Selector Netzwerke bestehen, die eine Migration unwirtschaftlich machen.

// Recoil selector — derived, memoized state computed from one or more atoms
import { selector, useRecoilValue } from 'recoil';
import { atom } from 'recoil';

const cartItemsState = atom({ key: 'cartItemsState', default: [] });

const cartTotalState = selector({
  key: 'cartTotalState',
  get: ({ get }) => {
    const items = get(cartItemsState);
    return items.reduce((sum, item) => sum + item.price * item.quantity, 0);
  },
});

function CartTotal() {
  const total = useRecoilValue(cartTotalState);
  return <p>Total: {total.toFixed(2)}</p>;
}

5. Jotai im Detail: Bottom Up Atoms ohne Boilerplate

Jotai übernimmt das Atom Modell von Recoil, verzichtet aber bewusst auf den verpflichtenden String Key pro Atom, wodurch Atoms in Jotai deutlich weniger Boilerplate benötigen und sich einfacher zwischen Modulen teilen lassen. Der bottom up Ansatz von Jotai bedeutet: Statt zuerst einen globalen Store zu definieren, entstehen Atoms dort im Code, wo sie gebraucht werden, und werden bei Bedarf zusammengesetzt, ähnlich wie useState, aber global teilbar.

Ein besonderes Feature von Jotai ist die native Unterstützung für asynchrone Atoms: Ein Atom kann direkt eine Promise zurückgeben, und React Suspense übernimmt automatisch die Ladezustand Darstellung, ohne dass zusätzlicher Code für Loading States geschrieben werden muss. In Kombination mit dem jotai/utils Paket, das unter anderem atomWithStorage für automatische LocalStorage Persistenz bereitstellt, deckt Jotai einen Großteil der Anwendungsfälle ab, für die früher Recoil oder eigene Context Lösungen nötig waren.

// Jotai — async atoms integrate directly with React Suspense
import { atom, useAtomValue } from 'jotai';
import { atomWithStorage } from 'jotai/utils';

const userIdAtom = atomWithStorage('userId', null); // persisted automatically

const userAtom = atom(async (get) => {
  const id = get(userIdAtom);
  if (!id) return null;
  const res = await fetch(`/api/users/${id}`);
  return res.json();
});

function UserProfile() {
  const user = useAtomValue(userAtom); // suspends automatically while pending
  return <p>{user?.name ?? 'Guest'}</p>;
}

6. Zustand im Detail: Ein Store, minimale API

Zustand verzichtet komplett auf das Atom Konzept und Context Provider, ein Store wird über eine einzige Funktion create definiert und liefert direkt einen Hook zurück, den Komponenten importieren und aufrufen können. Diese Einfachheit ist der Hauptgrund für die Popularität von Zustand: Kein Provider Wrapping in der Komponentenbaumstruktur nötig, kein Boilerplate für Actions, State und Updater Funktionen liegen im selben Objekt.

Middleware ist bei Zustand ein zentrales Erweiterungskonzept: persist synchronisiert den Store automatisch mit LocalStorage, devtools verbindet den Store mit den Redux DevTools für Time Travel Debugging, und immer erlaubt dieselbe direkte Mutations Schreibweise wie bei Redux Toolkit. Weil Zustand außerhalb von React Komponenten funktioniert, lässt sich der Store auch direkt in Event Handlern, Web Workern oder Service Klassen lesen und schreiben, ohne Hooks Regeln einzuhalten.

// Zustand — single store with persist middleware, no provider needed
import { create } from 'zustand';
import { persist } from 'zustand/middleware';

const useCartStore = create(
  persist(
    (set, get) => ({
      items: [],
      addItem: (item) =>
        set((state) => ({ items: [...state.items, item] })),
      removeItem: (id) =>
        set((state) => ({ items: state.items.filter((i) => i.id !== id) })),
      total: () => get().items.reduce((sum, i) => sum + i.price, 0),
    }),
    { name: 'cart-storage' } // persisted to localStorage automatically
  )
);

function CartBadge() {
  const itemCount = useCartStore((state) => state.items.length); // fine grained subscription
  return <span>{itemCount}</span>;
}

7. Server State Integration mit TanStack Query

Keine der drei Bibliotheken bringt eigenes Server State Caching mit, weshalb in der Praxis fast immer TanStack Query für Daten vom Server ergänzt wird, während Recoil, Jotai oder Zustand ausschließlich Client State verwalten. Die Integration verläuft bei allen drei technisch problemlos, weil TanStack Query unabhängig vom gewählten Client State Ansatz funktioniert und keine Provider Konflikte entstehen.

Ein feiner Unterschied: Jotai erlaubt durch seine async Atoms eine elegante Brücke zwischen beiden Welten, ein Atom kann intern queryClient.fetchQuery aufrufen und das Ergebnis wie einen normalen synchronen Wert im Rest der Anwendung bereitstellen. Bei Zustand und Recoil bleibt die Trennung zwischen Server State über TanStack Query Hooks und Client State über den jeweiligen Store oder die Atoms üblicherweise klarer getrennt, was für viele Teams tatsächlich die verständlichere Architektur ist.

8. Migration zwischen den Bibliotheken

Die häufigste Migration in der Praxis führt von Recoil zu Jotai, weil beide auf demselben Atom Prinzip basieren und sich die API Oberfläche in vielen Fällen fast eins zu eins übersetzen lässt. Ein Recoil atom({ key, default }) wird zu einem Jotai atom(default), ein Recoil selector wird zu einem abgeleiteten Jotai Atom mit einer Getter Funktion. Die größte manuelle Arbeit liegt im Entfernen der Recoil Root Provider Komponente, die bei Jotai standardmäßig nicht benötigt wird.

Eine Migration von Zustand zu einem Atom basierten Ansatz oder umgekehrt ist strukturell aufwendiger, weil sich das mentale Modell grundlegend ändert: Ein einzelner Store mit Selektor Funktionen muss in viele unabhängige Atoms aufgebrochen werden, oder umgekehrt müssen viele Atoms in ein zentrales Store Objekt zusammengeführt werden. Solche Migrationen lohnen sich meist nur, wenn konkrete Performance oder Wartbarkeitsprobleme im aktuellen Ansatz identifiziert wurden, nicht als reine Geschmacksfrage.

9. Die Entscheidungsmatrix im direkten Vergleich

Die folgende Matrix fasst die praxisrelevanten Kriterien zusammen und macht die Empfehlung für ein konkretes Projekt schneller nachvollziehbar als abstrakte Diskussionen über Philosophie.

10. Zusammenfassung

Die Wahl zwischen Recoil, Jotai und Zustand hängt vor allem vom bevorzugten mentalen Modell und vom aktuellen Wartungsstatus ab. Recoil war Vorreiter des Atom Konzepts, gilt 2026 aber wegen der verlangsamten Entwicklung nicht mehr als erste Wahl für neue Projekte. Jotai übernimmt die Atom Idee, reduziert Boilerplate weiter und bietet native Suspense Integration für asynchrone Werte, was es zur naheliegenden Wahl für feingranulare, organisch wachsende State Strukturen macht.

Zustand verzichtet komplett auf Atoms und Provider, bietet dafür die kleinste Bundle Size, funktioniert auch außerhalb von React und punktet mit einer minimalen, leicht erlernbaren API. Für die meisten neuen React Projekte im Jahr 2026 lautet die pragmatische Empfehlung: Jotai für feingranulare, unabhängige Zustandseinheiten, Zustand für einen einzigen, übersichtlichen globalen Store, und in beiden Fällen TanStack Query für alles, was vom Server kommt.

11. FAQ: Recoil vs Jotai vs Zustand