React State Management 2026: Ein datenbasierter Vergleich

Die State-Management-Landschaft für React hat sich in den letzten zwei Jahren dramatisch verändert. Redux ist nicht mehr der Standard. Recoil ist archiviert. Signals stecken immer noch im Komitee fest. Und eine neue Generation von kleinen, fokussierten Libraries hat das Ruder übernommen.

Wir nutzen aktuell Zustand und evaluieren Alternativen, darunter Nanostores, native React-Lösungen und andere aufkommende Pakete. Statt uns auf Bauchgefühl zu verlassen, haben wir Live-Daten von npm, GitHub und Entwicklerumfragen herangezogen, um eine fundierte Entscheidung zu treffen.

Alle Zahlen stammen aus der npm Registry API vom 25. Februar 2026.

Wichtigste Erkenntnis: Zustand hat Redux als meistgeladene dedizierte State-Management-Library überholt. Das TanStack-Ökosystem ist mit 7,2 Mio. kombinierten Downloads eine überraschende dritte Kraft. Unter den modernen leichtgewichtigen Alternativen führt Jotai mit 2,9 Mio., während Nanostores schnell wächst, aber noch eine Größenordnung kleiner ist.

Wöchentliche Snapshots erzählen nur einen Teil der Geschichte. Das folgende Diagramm zeigt monatlich aggregierte Downloads aus der npm-API über die letzten 12 Monate. Die Wachstumskurven zeigen, wo das Momentum liegt.

Zustands Vorsprung beschleunigt sich, statt zu stagnieren. Die monatlichen Downloads haben sich von 26,7 Mio. auf 72,9 Mio. fast verdreifacht. Redux Toolkit wuchs ebenfalls, aber langsamer — eine Verdopplung von 18,3 Mio. auf 37,1 Mio.

Die Libraries im Mittelfeld (XState, MobX, Jotai) liegen zwischen 8–12 Mio. monatlichen Downloads, alle mit stetigem, aber unspektakulärem Wachstum von 30–70 %.

Doch wenn man in die kleineren Libraries hineinzoomt, zeigt sich die eigentliche Überraschung:

Nanostores ist die Breakout-Story. Die monatlichen Downloads stiegen von 737K auf 4,9 Mio. — ein 6,6-facher Anstieg in 12 Monaten. Das ist proportional schnelleres Wachstum als bei jeder anderen Library in diesem Vergleich. Viel davon wird durch das Astro-Ökosystem getrieben, das Nanostores als Standard-State-Lösung übernommen hat, aber die Entwicklung ist unbestreitbar.

Jotai hat in diesem Zeitraum die Schwelle von „vielversprechend" zu „etabliert" überschritten und sich bei rund 9–10 Mio. monatlich stabilisiert. Valtio bleibt konstant, hat aber nicht denselben Wachstumsgang gefunden.

Die GitHub-Aktivität einer Library verrät, ob sie nächstes Jahr noch existieren wird. Daten abgerufen über die GitHub-API am 25. Februar 2026.

Was auffällt:

• Zustand und Jotai haben bemerkenswert wenige offene Issues (4 und 3) trotz massiver Verbreitung — ein Zeichen für gut gepflegte, stabile Codebases.
• Valtio zeigt ebenfalls exzellente Wartung mit nur 2 offenen Issues.
• Legend State hat 210 offene Issues bei nur 4K Stars — das ist bedenklich.
• TanStack Store hat wenige Stars, weil es neu ist und hauptsächlich intern von TanStack Router/Query genutzt wird — die Download-Zahlen erzählen aber eine andere Geschichte.

Wie kürzlich eine Library ein Release hatte, zeigt, ob sie aktiv weiterentwickelt oder nur noch gewartet wird.

Jede Library außer Recoil und MobX wurde innerhalb der letzten 3 Monate veröffentlicht. Dass Nanostores 1.0.0 und 1.1.0 erreicht hat, deutet auf eine stabilisierte API hin.

Bundle-Größe ist wichtig — vor allem für clientseitigen State, der an jeden Nutzer ausgeliefert wird. Ungefähre Größen basierend auf Bundlephobia-Daten und Paketanalyse:

Die State of React 2025 Umfrage (veröffentlicht Februar 2026) liefert uns harte Nutzungszahlen über drei Jahre:

• Zustand hat die 50-%-Nutzungsmarke überschritten (28 % → 41 % → 50 % von 2023 bis 2025) — fast eine Verdopplung in zwei Jahren.
• Redux (plain) ist mit 75,5 % immer noch am weitesten verbreitet, fällt aber von 80,5 % in 2023. Redux Toolkit stagniert bei ~54 %.
• Jotai wuchs stetig von 13 % auf 19 % — noch nischig, aber mit Beschleunigung.
• 34 % der Befragten nutzen gar keine State-Management-Library — useState und useContext reichen aus.
• Die größten Schmerzpunkte über alle Libraries hinweg: Übermäßige Komplexität (20 %) und Boilerplate (15 %) — beides Bereiche, in denen Zustand und Jotai glänzen.
• Der Trend ist unverkennbar: Entwickler bewegen sich hin zu einfacheren, weniger opinionated Tools.

Zahlen sind toll, aber wie fühlt sich jede Library in einer echten Codebase an? Finden wir es heraus.

Das Szenario: Ein Benachrichtigungs-Panel. Eine <NotificationBell> zeigt die Anzahl ungelesener Nachrichten, ein <NotificationPanel> zeigt die Liste mit Filterung, und jede Komponente kann Einträge als gelesen markieren. Server-Daten kommen von TanStack Query (mit codegen-generierten Options via OpenAPI-Codegen). Jede Library verpackt alles — Server-Daten, Client-UI-State, abgeleitete Werte und Mutations — hinter einem einzigen useNotifications()-Hook. Die Komponente konsumiert nur noch.

Alle Beispiele sind TypeScript. Server-Daten kommen von TanStack Query mit codegen-generierten Options (das moderne Pattern — keine Wrapper-Hooks, nur Query Option Factories, die in useQuery/useMutation gespreizt werden):

ts
// Generiert durch deinen OpenAPI/GraphQL-Codegen (z.B. @hey-api/openapi-ts, orval, graphql-codegen)
const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });

useNotifications.tsx
type Filter = "all" | "unread";

const NotificationCtx = createContext<ReturnType<typeof useNotificationsInner> | null>(null);

function useNotificationsInner() {
  const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
  const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });
  const [isOpen, setIsOpen] = useState(false);
  const [filter, setFilter] = useState<Filter>("all");

  const filtered = filter === "unread" ? notifications.filter((n) => !n.read) : notifications;
  const unreadCount = notifications.filter((n) => !n.read).length;

  return {
    notifications: filtered,
    unreadCount,
    isOpen,
    toggle: () => setIsOpen((o) => !o),
    filter,
    setFilter,
    markAsRead,
  };
}

export function NotificationProvider({ children }: { children: React.ReactNode }) {
  const value = useNotificationsInner();
  return <NotificationCtx value={value}>{children}</NotificationCtx>;
}

export function useNotifications() {
  const ctx = useContext(NotificationCtx);
  if (!ctx) throw new Error("Missing NotificationProvider");
  return ctx;
}

NotificationBell.tsx
function NotificationBell() {
  const { unreadCount, toggle } = useNotifications();
  return (
    <button onClick={toggle}>
      Notifications {unreadCount > 0 && `(${unreadCount})`}
    </button>
  );
}

Die Komponente ist sauber — aber es kostet ~30 Zeilen Provider-Boilerplate. Der Provider muss deinen Baum umschließen, und jeder Consumer rendert neu, wenn sich irgendetwas ändert: isOpen toggeln rendert die Bell, die Filter-Buttons, die Liste — alles. Um das zu beheben, müsstest du in mehrere Contexts aufteilen, was den Boilerplate vervielfacht.

useNotifications.ts
type Filter = "all" | "unread";

const useNotificationUI = create<{
  isOpen: boolean;
  filter: Filter;
  toggle: () => void;
  setFilter: (filter: Filter) => void;
}>()((set) => ({
  isOpen: false,
  filter: "all",
  toggle: () => set((s) => ({ isOpen: !s.isOpen })),
  setFilter: (filter) => set({ filter }),
}));

export function useNotifications() {
  const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
  const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });
  const { isOpen, filter, toggle, setFilter } = useNotificationUI();

  const filtered = filter === "unread" ? notifications.filter((n) => !n.read) : notifications;
  const unreadCount = notifications.filter((n) => !n.read).length;

  return { notifications: filtered, unreadCount, isOpen, toggle, filter, setFilter, markAsRead };
}

NotificationBell.tsx
function NotificationBell() {
  const { unreadCount, toggle } = useNotifications();
  return (
    <button onClick={toggle}>
      Notifications {unreadCount > 0 && `(${unreadCount})`}
    </button>
  );
}

Kein Provider. Der Store hält den UI-State, der Hook kombiniert ihn mit TanStack Query und bietet ein einziges sauberes Interface. Types werden vollständig inferiert. Für feinere Re-Renders können Komponenten auch direkt aus dem Store selektieren: useNotificationUI((s) => s.isOpen).

useNotifications.ts
const isOpenAtom = atom(false);
const filterAtom = atom<"all" | "unread">("all");

export function useNotifications() {
  const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
  const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });
  const [isOpen, setIsOpen] = useAtom(isOpenAtom);
  const [filter, setFilter] = useAtom(filterAtom);

  const filtered = filter === "unread" ? notifications.filter((n) => !n.read) : notifications;
  const unreadCount = notifications.filter((n) => !n.read).length;

  return {
    notifications: filtered,
    unreadCount,
    isOpen,
    toggle: () => setIsOpen((o) => !o),
    filter,
    setFilter,
    markAsRead,
  };
}

NotificationBell.tsx
function NotificationBell() {
  const { unreadCount, toggle } = useNotifications();
  return (
    <button onClick={toggle}>
      Notifications {unreadCount > 0 && `(${unreadCount})`}
    </button>
  );
}

Atoms sind die dünnste Store-Definition überhaupt — zwei Zeilen. Der komponierende Hook sieht fast identisch aus wie die Zustand-Version. Wo Jotai glänzt, ist Derived State: Wenn du ein berechnetes Atom brauchst, das von filterAtom und Query-Daten abhängt, erledigt atom((get) => ...) das elegant. Der Trade-off: Atoms sind lose Teile, kein einzelner kohärenter Store, was in größeren Apps Disziplin erfordert.

notification-store.ts
import { atom } from "nanostores";

export const $isOpen = atom(false); // $-Prefix ist Nanostores-Konvention, nicht erforderlich
export const $filter = atom<"all" | "unread">("all");

export const toggle = () => $isOpen.set(!$isOpen.get());
export const setFilter = (f: "all" | "unread") => $filter.set(f);

useNotifications.ts
import { useStore } from "@nanostores/react";

export function useNotifications() {
  const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
  const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });
  const isOpen = useStore($isOpen);
  const filter = useStore($filter);

  const filtered = filter === "unread" ? notifications.filter((n) => !n.read) : notifications;
  const unreadCount = notifications.filter((n) => !n.read).length;

  return { notifications: filtered, unreadCount, isOpen, toggle, filter, setFilter, markAsRead };
}

NotificationBell.tsx
function NotificationBell() {
  const { unreadCount, toggle } = useNotifications();
  return (
    <button onClick={toggle}>
      Notifications {unreadCount > 0 && `(${unreadCount})`}
    </button>
  );
}

State und Actions leben in einem normalen Modul — keine Hooks, keine React-API, bis der komponierende Hook useStore aufruft. Deshalb funktioniert Nanostores identisch über React, Vue, Svelte und Astro-Islands hinweg. Die $-Prefix-Konvention ist von Svelte Stores übernommen.

notification-store.ts
import { proxy } from "valtio";

export const notificationUI = proxy({
  isOpen: false,
  filter: "all" as "all" | "unread",
});

export const toggle = () => {
  notificationUI.isOpen = !notificationUI.isOpen;
};
export const setFilter = (f: "all" | "unread") => {
  notificationUI.filter = f;
};

useNotifications.ts
import { useSnapshot } from "valtio";

export function useNotifications() {
  const { data: notifications = [] } = useQuery({ ...getNotificationsOptions() });
  const { mutate: markAsRead } = useMutation({ ...markNotificationAsReadOptions() });
  const { isOpen, filter } = useSnapshot(notificationUI);

  const filtered = filter === "unread" ? notifications.filter((n) => !n.read) : notifications;
  const unreadCount = notifications.filter((n) => !n.read).length;

  return { notifications: filtered, unreadCount, isOpen, toggle, filter, setFilter, markAsRead };
}

NotificationBell.tsx
function NotificationBell() {
  const { unreadCount, toggle } = useNotifications();
  return (
    <button onClick={toggle}>
      Notifications {unreadCount > 0 && `(${unreadCount})`}
    </button>
  );
}

Der Store nutzt einfache Mutationen — notificationUI.isOpen = true — während useSnapshot eine immutable Ansicht zum Rendern liefert. Valtio trackt, welche Properties jede Komponente zugreift, und rendert nur neu, wenn sich diese ändern. Der Trade-off: Proxy-Verhalten kann überraschen (Equality-Checks, Frozen Objects, Prototype-Chains).

Jede Komponente sieht identisch aus — const { unreadCount, toggle } = useNotifications(). Der Unterschied liegt ausschließlich darin, wie der Hook gebaut wird.

*Jotai braucht einen Provider nur für SSR oder Test-Isolation

Die Erkenntnis: Jede moderne Library ermöglicht denselben sauberen useNotifications()-Hook ohne Provider. TanStack Query liefert die Server-Daten, die State-Library verwaltet den UI-State, und der komponierende Hook verschmilzt beides zu einem Interface. Die Wahl hängt davon ab, wie du State am liebsten definierst — ein Store (Zustand), unabhängige Atoms (Jotai/Nanostores) oder mutable Objekte (Valtio).

Zustand ist in der React-Community zur „nimm einfach das"-Empfehlung geworden, und die Zahlen belegen es.

tsx
import { create } from "zustand";

const useStore = create((set) => ({
  count: 0,
  increment: () => set((state) => ({ count: state.count + 1 })),
}));

function Counter() {
  const count = useStore((state) => state.count);
  const increment = useStore((state) => state.increment);
  return <button onClick={increment}>{count}</button>;
}

Stärken:

• Minimale API, fast kein Boilerplate
• Kein Provider-Wrapper nötig
• Funktioniert außerhalb von React (Vanilla JS, Middleware)
• Hervorragender TypeScript-Support
• Selector-basierte Re-Render-Optimierung
• Middleware-Ökosystem (persist, devtools, immer)
• Aktive Entwicklung durch das pmndrs-Kollektiv (Dai Shi)

Schwächen:

• Selector-Patterns können bei komplexem State verbose werden
• Kein eingebauter computed/derived State (braucht Middleware)
• Single-Store-Pattern kann zu großen Store-Dateien führen

Am besten für: Die meisten React-Anwendungen. Die sichere, langweilige, richtige Wahl.

Jotai verfolgt einen Bottom-up-Ansatz, inspiriert von Recoil, aber ohne den Ballast. Jedes Stück State ist ein unabhängiges Atom.

tsx
import { atom, useAtom } from "jotai";

const countAtom = atom(0);
const doubledAtom = atom((get) => get(countAtom) * 2);

function Counter() {
  const [count, setCount] = useAtom(countAtom);
  return <button onClick={() => setCount((c) => c + 1)}>{count}</button>;
}

function Display() {
  const [doubled] = useAtom(doubledAtom);
  return <span>{doubled}</span>;
}

Stärken:

• Derived/computed State ist ein erstklassiges Konzept
• Komponenten rendern nur neu, wenn sich ihre spezifischen Atoms ändern
• Hervorragend für komplexen, voneinander abhängigen State
• Kleines Bundle, großartiger TypeScript-Support
• Code-Splitting auf Atom-Ebene
• Integration mit asynchronen Daten (Suspense-kompatible Atoms)

Schwächen:

• Mentaler Modellwechsel weg von zentralisierten Stores
• Atom-Proliferation in großen Apps erfordert Disziplin
• Debugging kann schwieriger sein (State ist verteilt)

Am besten für: Anwendungen mit komplexem, voneinander abhängigem State. Form-Builder, Dashboards mit vielen berechneten Werten.

Nanostores ist die mit Abstand kleinste State-Management-Library. Erstellt von Andrey Sitnik (dem Autor von PostCSS und Autoprefixer), verfolgt sie einen framework-agnostischen, atomaren Ansatz.

tsx
import { atom, computed } from "nanostores";
import { useStore } from "@nanostores/react";

const $count = atom(0);
const $doubled = computed($count, (count) => count * 2);

function Counter() {
  const count = useStore($count);
  return <button onClick={() => $count.set(count + 1)}>{count}</button>;
}

Stärken:

• 286 Bytes. Das ist kein Tippfehler.
• Framework-agnostisch (React, Vue, Svelte, Solid, Angular, Lit)
• Null Abhängigkeiten
• Einfache, vorhersehbare API
• Ideal für Multi-Framework-Projekte (Astro)
• Stabile 1.0 API

Schwächen:

• Kleinere Community und Ökosystem
• Weniger Middleware/Plugins als Zustand
• Weniger React-spezifische Ergonomie (imperatives .set() statt Hooks)
• Dokumentation ist dünner als bei den großen Konkurrenten
• @nanostores/react-Adapter erhöht die Basisgröße

Am besten für: Bundle-kritische Anwendungen, Multi-Framework-Projekte, Astro-Sites, Teams die radikale Einfachheit schätzen.

Valtio nutzt JavaScript Proxies, um State-Mutationen natürlich wirken zu lassen, während React unter der Haube mit immutablen Snapshots zufrieden gehalten wird.

tsx
import { proxy, useSnapshot } from "valtio";

const state = proxy({ count: 0 });

function Counter() {
  const snap = useSnapshot(state);
  return <button onClick={() => state.count++}>{snap.count}</button>;
}

Stärken:

• Intuitivste API (einfach Objekte mutieren)
• Automatisches Tracking der zugegriffenen Properties
• Funktioniert gut mit verschachteltem State
• Wenig Boilerplate

Schwächen:

• Proxy-Verhalten kann überraschen (Equality, Frozen Objects)
• Schwerer zu debuggen (Mutationen passieren außerhalb von Reacts Modell)
• Kleineres Ökosystem als Zustand

Am besten für: Teams, die von MobX oder Vanilla JS kommen und immutable Patterns nervig finden.

RTK hat Redux mit opinionated Defaults modernisiert, aber unter der Haube ist es immer noch Redux.

Stärken:

• Battle-tested im großen Maßstab (Meta, Amazon etc.)
• RTK Query für Data Fetching
• Time-Travel-Debugging mit Redux DevTools
• Riesiges Ökosystem und Talent-Pool
• Strukturierte Patterns profitieren große Teams

Schwächen:

• Immer noch groß (~12 KB gzipped)
• Boilerplate wurde reduziert, aber nicht eliminiert
• Slices, Selectors, Dispatching: steilere Lernkurve
• Hohe negative Stimmung in den State of React Umfragen

Am besten für: Große Enterprise-Teams mit bestehender Redux-Infrastruktur. Neue Projekte sollten es sich zweimal überlegen.

XState bringt formale State Machines nach JavaScript. Das neue @xstate/store extrahiert das einfache event-gesteuerte Pattern ohne den vollen State-Machine-Overhead.

Am besten für: Komplexe Workflows (Wizards, Zahlungsabläufe, mehrstufige Prozesse). Das volle XState ist Overkill für einfachen UI-State.

TanStack Store ist ein überraschender Eintrag in den Charts. Mit 7,2 Mio. wöchentlichen Downloads sieht es nach einem großen Player aus, aber der Kontext ist entscheidend: Die überwiegende Mehrheit dieser Downloads stammt davon, dass es eine interne Abhängigkeit von TanStack Router, TanStack Table und anderen TanStack-Tools ist — nicht von eigenständiger Nutzung. Die 790 GitHub-Stars erzählen eine andere Geschichte als die Download-Zahlen.

tsx
import { Store } from "@tanstack/store";
import { useStore } from "@tanstack/react-store";

const store = new Store({ count: 0 });

function Counter() {
  const count = useStore(store, (s) => s.count);
  return (
    <button onClick={() => store.setState((s) => ({ ...s, count: s.count + 1 }))}>
      {count}
    </button>
  );
}

Stärken:

• Framework-agnostisch (React, Vue, Solid, Angular, Svelte)
• TypeScript-first mit exzellenter Type Inference
• Backed by das TanStack-Ökosystem (Tanner Linsley)
• Selector-basierte Re-Render-Optimierung
• Kein Provider nötig

Schwächen:

• Die meisten Downloads sind transitiv, nicht bewusste Adoption
• Winzige Community (790 Stars, wenig Diskussionen)
• Spärliche Dokumentation — hauptsächlich API-Referenz, wenige Guides
• Kein Middleware-Ökosystem (kein persist, keine DevTools)
• Unreif im Vergleich zu Zustand und Jotai

Am besten für: Projekte, die bereits tief im TanStack-Ökosystem stecken (Router, Table, Query) und eine konsistente API über ihren Stack hinweg wollen. Als eigenständige Wahl noch nicht überzeugend genug.

• MobX (28K Stars, 2,9 Mio. Downloads): Ausgereift und stabil, hat aber seit September 2025 nichts mehr veröffentlicht. Observable-basierte Reactivity. Wenn du es bereits nutzt, kein Grund zur Eile beim Migrieren. Wenn nicht, gibt es auch keinen Grund anzufangen.
• @legendapp/state (4K Stars, 45K Downloads): Behauptet, die schnellste zu sein mit Fine-grained Reactivity und eingebauter Persistence/Sync. Interessant für React Native. Aber 210 offene Issues bei 4K Stars ist ein Warnsignal.
• @preact/signals-react (4,4K Stars, 246K Downloads): Umgeht Reacts Rendering-Modell komplett für maximale Performance. Fragil bei React-Versionswechseln und inkompatibel mit Server Components. Das React-Team hat explizit gesagt, dass Signals gegen Reacts Modell verstoßen.
• Effector (4,8K Stars, 62K Downloads): Event-gesteuerte reaktive State-Verwaltung mit einer starken Anhängerschaft in der russischsprachigen Community. Hervorragend für komplexe Business-Logik, aber eine Nische.

Bevor du zu einer Library greifst, überlege, ob Reacts eingebaute Primitives ausreichen.

• use Hook für das Konsumieren von Promises und Context
• useActionState für Formular-State mit Server Actions
• useOptimistic für optimistische UI-Updates
• Verbesserter Context mit dem <Context value={}> Shorthand

Der React Compiler ist als Stable erschienen und bietet automatische Memoization zur Build-Zeit. Das schwächt eines der Hauptargumente für externes State Management: Performance-Optimierung. Wenn React selbst die Memoization übernimmt, verliert das Re-Render-Optimierungs-Argument für Signals und Proxies erheblich an Gewicht.

Metas eigene Daten zeigen bis zu 12 % schnellere Initial Loads und 2,5x schnellere Interaktionen mit aktiviertem Compiler.

Die developerway.com-Analyse schlüsselt es gut auf:

1. Server State (~80 % von dem, was früher Redux war): Nutze TanStack Query oder SWR
2. URL State (~10 %): Nutze nuqs oder deinen Router
3. Lokaler Komponenten-State: useState / useReducer
4. Geteilter Komponenten-State: Prop Drilling oder Context für 1–2 Concerns

Du brauchst eine externe State-Management-Library erst dann, wenn du 3+ geteilte clientseitige Concerns hast, die Context ohne „Provider-Hölle" nicht bewältigen kann.

Der TC39 Signals-Proposal verbleibt per Februar 2026 bei Stage 1. Das Komitee verfolgt einen konservativen Ansatz und verlangt reale Integrationen in mehrere Frameworks, bevor es weitergeht. Angular, Solid, Vue und Preact unterstützen ihn. Das React-Team nicht — mit der Begründung, dass Signals mit Reacts „UI als Funktion von State"-Modell kollidieren.

Wette deine Architektur nicht auf TC39 Signals. Falls sie jemals in der Spec landen, wird es Jahre dauern, und React wird sie möglicherweise nie direkt übernehmen.

*Die meisten TanStack-Store-Downloads sind transitiv (von TanStack Router, Table etc.), nicht eigenständige Nutzung.

Es gibt keine universelle Antwort, aber so denken wir darüber:

Für die meisten React-Projekte: Zustand ist der sichere, pragmatische Standard. Klein, gut gewartet, die größte moderne Community und das einfachste mentale Modell. Die 4 offenen Issues bei 57K Stars sprechen Bände.

Bei komplexem derived State: Jotai ist die bessere Wahl. Das atomare Modell mit erstklassigen computed Atoms behandelt komplexe Abhängigkeiten eleganter als Zustands Selectors.

Wenn Bundle-Größe entscheidend ist: Nanostores gewinnt mit 286 Bytes. Es ist auch die richtige Wahl für Multi-Framework-Projekte (Astro, Mischung aus React mit anderen Frameworks). Aber man tauscht Ökosystem-Größe und React-spezifische Ergonomie gegen minimalen Footprint.

Wenn du Proxy-basierte Mutationen brauchst: Valtio bietet die natürlichste API für Entwickler, die immutable Patterns umständlich finden. Gleicher Autor wie Zustand (Dai Shi), die Qualität stimmt also.

Wenn du bereits auf Redux bist: Redux Toolkit ist in Ordnung. Kein Grund, nur um der Sache willen zu migrieren. Aber für neue Projekte ist der Overhead schwer zu rechtfertigen.

Wenn du tief im TanStack-Ökosystem steckst: TanStack Store gibt dir eine konsistente API neben Router und Table. Aber als eigenständige State-Management-Wahl bietet es noch nicht genug gegenüber Zustand oder Jotai, um die kleinere Community und das fehlende Ökosystem zu rechtfertigen.

Der TanStack Query + Zustand Stack (oder Jotai) ist der aufkommende Standard für 2026: Server State in TanStack Query, Client State in einem leichtgewichtigen Store.

Alle Daten in diesem Artikel wurden am 25. Februar 2026 erhoben aus:

• npm Downloads API

  Wöchentliche Download-Zahlen für alle Pakete, abgerufen am 25. Februar 2026.

• GitHub REST API

  Stars, offene Issues, letzte Push-Daten und Archivierungsstatus für alle Repositories.

• State of React 2025 Umfrage

  Zufriedenheits- und Nutzungsdaten von Entwicklern für State-Management-Libraries (2025er-Ausgabe).

• State of React 2024 Umfrage

  Zufriedenheits- und Nutzungsdaten von Entwicklern für State-Management-Libraries (2024er-Ausgabe).

• React State Management in 2025: What You Actually Need

  Nadia Makarevichs Analyse, wann man tatsächlich eine State-Management-Library braucht.

• Top 5 React State Management Tools in 2026

  Syncfusions Vergleich der führenden State-Management-Lösungen.

• State Management Trends in React 2025

  Wann man Zustand, Jotai, XState oder etwas anderes nutzen sollte.

• React Compiler v1.0 Release

  Automatische Memoization zur Build-Zeit, stabil seit Oktober 2025.

• TC39 Signals Proposal

  Der Stage-1-Proposal, um reaktive Signals zu JavaScript hinzuzufügen.

• npm Trends Vergleich

  Interaktiver Download-Trend-Vergleich verschiedener State-Management-Libraries.