Sascha Becker

2026

25. Februar 2026

React State Management 2026: Ein datenbasierter Vergleich

Zustand, Jotai, Nanostores, Redux Toolkit, Valtio, XState und mehr. Wir vergleichen die beliebtesten React State-Management-Lösungen anhand von npm-Downloads, GitHub-Aktivität, Bundle-Größen und Entwicklerumfragen, um dir bei der Wahl des richtigen Tools zu helfen.

Sascha Becker

Author

21 Min. Lesezeit

React State Management 2026: Ein datenbasierter Vergleich | Sascha Becker

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.

Die Zahlen: npm Wöchentliche Downloads

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

npm Weekly Downloads (Feb 25, 2026)

Market share by weekly downloads. Zustand and Redux together account for over 60% of all state management downloads.

Zustand
Redux
RTK
TanStack
XState
Jotai
MobX
Nanostores
Valtio
Others

Kontext ist wichtig

Rohe Download-Zahlen beinhalten CI-Pipelines, Bots und transitive Abhängigkeiten. Die hohen Redux-Zahlen spiegeln teilweise Legacy-Projekte wider, in denen RTK Redux als Dependency mitzieht. Dass Zustand Redux bei den reinen Downloads überholt hat, ist die eigentliche Geschichte von 2025-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.

12-Monats-Trend: Das Gesamtbild

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.

npm Monthly Downloads (Mar 2025 – Feb 2026)

Data from the npm registry API. Feb 2026 is partial (1st–25th).

Zustand
Redux Toolkit
XState
MobX
Jotai
Valtio
Nanostores

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:

The Challengers: Jotai vs Nanostores vs Valtio

Nanostores grew 6.6x in 12 months, the fastest growth of any library in this comparison.

Jotai
Nanostores
Valtio

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.

GitHub Health Check

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.

Library	Stars	Offene Issues	Archiviert?
Zustand	57,1K	4	Nein
XState	29,3K	165	Nein
MobX	28,2K	86	Nein
Jotai	21,0K	3	Nein
Recoil	19,5K	322	Ja

Recoil ist tot

Recoil wurde Anfang 2025 von Meta archiviert. Die 322 offenen Issues werden nie gelöst. Wenn du es noch nutzt, migriere jetzt. Jotai ist der nächste geistige Nachfolger.

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.

Zuletzt auf npm veröffentlicht

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

Library	Version	Zuletzt veröffentlicht
@xstate/store	3.16.0	25. Feb 2026
Jotai	2.18.0	19. Feb 2026
@legendapp/state	2.1.15	19. Feb 2026
@tanstack/react-store	0.9.1	17. Feb 2026
@preact/signals-react	3.9.0	13. Feb 2026
XState	5.28.0	12. Feb 2026

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

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:

Bundle Size Comparison (min + gzip)

Kilobytes shipped to the client. Nanostores at 0.3 KB is 40x smaller than Zustand.

Entwicklerstimmung

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.

Praxisvergleich: Ein Feature, fünf Wege

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(),
});

React Context (Baseline)


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.

Zustand


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).

Jotai


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.

Nanostores


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.

Valtio


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).

Kopf an Kopf

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

	Context	Zustand	Jotai	Nanostores	Valtio
Store-Definition	N/A (inline)	~10 Zeilen	~2 Zeilen	~6 Zeilen	~10 Zeilen
Kompositions-Hook	Im Provider integriert	~10 Zeilen	~12 Zeilen	~10 Zeilen	~10 Zeilen
Provider nötig	Ja	Nein	Nein*	Nein	Nein
Type Inference

*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).

Die Kandidaten: Deep Dive

Zustand — Der neue Standard

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 — Atomare Präzision

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 — Radikaler Minimalismus

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 — Proxy-Magie

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.

Redux Toolkit — Der Enterprise-Standard

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 & @xstate/store — State Machines

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 — Der stille Riese

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.

Die Anderen

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.

Die Native-React-Story

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

React 19 brachte:

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

React Compiler (v1.0, Oktober 2025):

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.

Wann eingebauter State reicht:

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

Server State (~80 % von dem, was früher Redux war): Nutze TanStack Query oder SWR
URL State (~10 %): Nutze nuqs oder deinen Router
Lokaler Komponenten-State: useState / useReducer
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

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.

Entscheidungsmatrix

Kriterium	Zustand	Jotai	Nanostores	Valtio	RTK	TanStack Store
Bundle-Größe	1,2 KB	3,5 KB	0,3 KB	3,2 KB	12 KB	1,4 KB
Lernkurve	Niedrig	Mittel	Niedrig	Niedrig	Hoch	Niedrig
TypeScript DX	Exzellent	Exzellent	Gut	Gut	Gut

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

Unsere Empfehlung

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.

Quellen

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