Was ist TanStack? Wahrscheinlich läuft es längst in einem deiner Projekte, ohne dass es in einem Statusbericht je so genannt wurde. Wenn dein Frontend-Team irgendwann „React Query" eingeführt hat, um Serverdaten sauber zu laden und zu cachen, dann ist das heute TanStack Query. Der Name hat sich geändert, die Bibliothek ist dieselbe geblieben. Und sie ist riesig: Allein der React-Adapter wird über zehn Millionen Mal pro Woche heruntergeladen, was TanStack Query zu einer der meistgenutzten Frontend-Bibliotheken überhaupt macht.
Trotzdem stiftet der Begriff Verwirrung. TanStack klingt nach einem weiteren JavaScript-Framework, das mit React, Vue oder Angular konkurriert. Das ist es nicht. TanStack ist eine Sammlung von Open-Source-Bibliotheken für den Bau moderner Web-Anwendungen: headless, typsicher und in den meisten Fällen Framework-unabhängig. Sie ersetzen dein Framework nicht, sie ergänzen es um genau die Bausteine, die jedes ernsthafte Projekt früher oder später selbst nachbaut: Datenladen, Routing, Tabellen, Formulare, Virtualisierung.
Dieser Beitrag ordnet ein, was hinter dem Namen steckt, welche Bibliotheken zum Stack gehören, welche davon produktionsreif sind und welche nicht, und warum das Thema auch für E-Commerce- und Headless-Commerce-Projekte relevant ist. Kein Tutorial, sondern die Entscheider-Perspektive: Was bekomme ich, was riskiere ich, und wann lohnt es sich.
Was TanStack ist, und was nicht
Die häufigste Fehleinordnung zuerst: TanStack tritt nicht gegen React an. Es setzt darauf auf. Du wählst weiterhin dein Framework (React, Vue, Angular, Solid, Svelte), und TanStack liefert die Funktionsschichten, die das Framework selbst bewusst offenlässt. React kümmert sich um das Rendern der Oberfläche. Wie du Serverdaten holst, cachest und synchron hältst, ist nicht Reacts Aufgabe, und genau diese Lücke füllt TanStack Query.
Der zweite Schlüsselbegriff ist headless. Eine headless Bibliothek liefert die Logik, aber kein fertiges Aussehen. TanStack Table zum Beispiel bringt die komplette Mechanik einer Datentabelle mit, also Sortierung, Filterung, Pagination, Spaltengruppierung und Zeilenauswahl, aber kein einziges vorgefertigtes Pixel. Markup und Styling bleiben vollständig bei dir. Für ein Team mit eigenem Designsystem ist das ein Vorteil, weil du keine fremde Optik erbst, die du erst mühsam überschreiben musst. Für ein Team, das schnell eine Standard-Tabelle braucht, ist es Mehraufwand. Headless ist also kein reines Plus, sondern eine bewusste Entscheidung gegen vorgefertigte Optik und für volle Kontrolle.
Hinter dem Projekt steht Tanner Linsley, der die Sammlung aus zwei ursprünglich React-spezifischen Bibliotheken entwickelt hat: React Query und React Table. Als beide den React-Bezug ablegten und für andere Frameworks geöffnet wurden, brauchte es einen neuen Dachnamen. Aus „React Query" wurde TanStack Query, aus „React Table" wurde TanStack Table, und seitdem ist eine ganze Familie von Bibliotheken dazugekommen. Heute vertrauen laut TanStack unter anderem Google, Amazon, Microsoft, Apple und Walmart in der Produktion auf Teile des Stacks. Das ist kein Marketing-Detail, sondern eine Risikoaussage: Du baust nicht auf einem Hobbyprojekt auf, das nächstes Jahr verwaist sein könnte. Was TanStack dagegen ausdrücklich nicht ist: ein fertiges Komponenten-Set von der Stange, ein Design-System wie Material UI oder eine gehostete Plattform mit Lizenzgebühr. Es ist Open Source unter MIT-Lizenz, Baustein für Baustein einzeln einsetzbar.
Die vier Prinzipien, und warum sie für Entscheider zählen
TanStack folgt durchgehend vier Leitlinien. Sie klingen technisch, haben aber direkte Konsequenzen für Budget, Risiko und Teamaufstellung.
Framework-agnostisch. Die meisten Bibliotheken bestehen aus einem Framework-neutralen Kern plus dünnen Adaptern für React, Vue, Solid, Svelte und Angular. Praktisch heißt das: Wechselt dein Team irgendwann das Frontend-Framework, nimmst du dein Wissen über das Daten- und Tabellen-Handling mit, statt es pro Framework neu zu lernen. Das senkt das Risiko, das in jeder Technologie-Entscheidung steckt, die ein Team auf Jahre bindet.
Typsicher von Grund auf. TanStack ist konsequent in TypeScript gebaut und gibt Typsicherheit bis in die Randbereiche durch, in denen andere Werkzeuge aufgeben, etwa bei URL-Parametern oder Formularfeldern. Der Compiler zeigt dir dadurch beim Umbau jede Stelle, die du nachziehen musst, statt dass ein Kunde den Fehler später im Checkout findet. Weniger Laufzeitfehler, sicherere Refactorings und damit Wartungskosten, die nicht mit jedem Umbau explodieren.
Produktionserprobt. Die Kern-Bibliotheken laufen in einigen der größten Web-Anwendungen der Welt. Für eine Architekturentscheidung ist das die halbe Miete: Du setzt nicht auf eine Wette, sondern auf Code, der unter echtem Last- und Skalierungsdruck steht.
Kein Vendor-Lock-in. Open Source, unabhängig, keine Plattformbindung. Du kannst eine einzelne Bibliothek einsetzen und den Rest ignorieren, und du kannst sie genauso wieder ausbauen. Die MIT-Lizenz bedeutet konkret: kommerziell nutzbar, keine Gebühr, kein Anbieter, der morgen sein Preismodell umstellt. Diese Freiheit hat eine Kehrseite, auf die ich beim Thema Lieferketten-Sicherheit zurückkomme.
Die Bibliotheken im Überblick
Der Stack umfasst inzwischen über ein Dutzend Bibliotheken. Du musst sie nicht alle kennen. Drei davon decken den Großteil der realen Anwendungsfälle ab, der Rest ist Spezialwerkzeug. Ich gehe sie nach Aufgabenfeld durch und beginne mit der wichtigsten.
Daten und Zustand
TanStack Query ist das Herzstück und der Grund, warum die meisten Teams überhaupt mit dem Stack in Berührung kommen. Es löst ein Problem, das auf den ersten Blick trivial wirkt und in der Praxis ganze Codebasen verschmutzt: das Laden, Cachen und Aktualisieren von Serverdaten. Ohne ein Werkzeug wie Query baut jedes Team früher oder später seinen eigenen, halbgaren Caching-Mechanismus, mit veralteten Daten, doppelten Requests und Ladezuständen, die niemand sauber verwaltet. Query nimmt dir das ab: Es cacht automatisch, lädt im Hintergrund nach, wiederholt fehlgeschlagene Requests und hält die Oberfläche konsistent. Es unterstützt React, Vue, Solid, Svelte, Angular und Lit. Wenn du nur eine einzige Bibliothek aus dem Stack einsetzt, ist es mit großer Wahrscheinlichkeit diese.
TanStack DB geht einen Schritt weiter und ist der spannendste Neuzugang. Es ist ein reaktiver, client-seitiger Datenspeicher, der auf Query aufsetzt und auf sogenanntem Differential Dataflow basiert. Vereinfacht: Die Oberfläche bleibt schnell und konsistent, auch wenn viele Daten im Spiel sind, weil nur die tatsächlichen Änderungen neu berechnet werden statt alles. DB steckt allerdings noch im Beta-Stadium, also interessant für Prototypen, aber noch nicht der Default für ein geschäftskritisches System.
Daneben gibt es TanStack Store (einen schlanken, reaktiven State-Container, der intern viele andere Bibliotheken antreibt) und TanStack AI (ein offenes SDK mit einheitlicher Schnittstelle zu verschiedenen KI-Anbietern, ohne Lock-in auf einen Provider). Beide sind im Alpha-Stadium und eher etwas für Teams, die früh experimentieren wollen.
Routing und Full-Stack
TanStack Router ist ein typsicherer Router, und Typsicherheit ist hier das ganze Verkaufsargument. Er erzeugt zur Build-Zeit einen vollständig typisierten Routenbaum: Jeder Pfadparameter, jeder Suchparameter in der URL, jeder geladene Datensatz ist TypeScript bekannt, ohne dass du eine einzige Typannotation von Hand schreibst. Wer schon einmal stundenlang einen Bug gejagt hat, der nur daran lag, dass ein URL-Parameter anders hieß als gedacht, versteht den Wert sofort. Anders als die Datenbibliotheken ist Router allerdings auf React und Solid beschränkt.
TanStack Start baut auf Router auf und ist das jüngste, ambitionierteste Stück: ein vollwertiges Full-Stack-Framework mit Server-Side-Rendering, Streaming und Server-Funktionen, aufgebaut auf Vite, lauffähig für React und Solid. Damit tritt TanStack in direkte Konkurrenz zu Next.js. Der konzeptionelle Unterschied: Start denkt zuerst client-seitig und ruft Server-Funktionen explizit auf, während Next.js mit React Server Components serverzentriert denkt. Start steht aktuell bei Version 1 als Release Candidate, die Funktionen sind also vollständig und die Schnittstelle gilt als stabil, aber die jahrelange Praxiserprobung und das Ökosystem von Next.js fehlen noch. Für ein neues Projekt mit Risikobereitschaft eine echte Option, für die konservative Wahl noch zu jung.
Oberfläche
TanStack Table ist nach Query die zweitbekannteste Bibliothek und der Goldstandard für komplexe Datentabellen. Überall, wo Nutzer große Mengen tabellarischer Daten sortieren, filtern und durchblättern müssen, etwa in Bestelllisten, Produktkatalogen oder Reporting-Dashboards, nimmt Table die gesamte Logik ab und überlässt dir das Aussehen. Es unterstützt praktisch alle gängigen Frameworks, für React, Vue, Solid, Svelte, Angular, Qwik und Lit.
TanStack Form schließt die letzte große Lücke: typsicheres, performantes Formular-Management für komplexe Eingabemasken mit vielen Feldern, Validierung und bedingter Logik. Mit sieben Framework-Adaptern gehört es zu den breitesten Angeboten im Stack und ist seit dem v1-Release produktionsreif. TanStack Virtual wiederum sorgt dafür, dass extrem lange Listen oder Tabellen flüssig bleiben, indem es nur die tatsächlich sichtbaren Zeilen rendert, relevant überall dort, wo Tausende Datensätze auf einer Seite scrollbar sein müssen.
Kleineres Werkzeug und das Tooling
Der Rest ist Spezialwerkzeug, das du nur bei Bedarf brauchst: Pacer für Debouncing, Throttling und Rate-Limiting (Beta), Hotkeys für Tastaturkürzel, Devtools als gemeinsames Debugging-Panel sowie CLI und Intent für Tooling und KI-Integration. Diese tragen noch Alpha-Etiketten und sollten in der Entscheidung für oder gegen TanStack keine tragende Rolle spielen.
Welche Bibliothek kannst du heute produktiv einsetzen?
Das ist die Frage, auf die es für eine Architekturentscheidung ankommt. TanStack vergibt selbst Reifegrade von Alpha über Beta und Release Candidate bis stabil, und diese Etiketten sind ernst zu nehmen. Die folgende Einordnung trennt das Produktionsreife vom Experimentellen:
| Bibliothek | Aufgabe | Reifegrad | Produktiv einsetzbar? |
|---|---|---|---|
| Query | Serverdaten laden & cachen | stabil | Ja, uneingeschränkt |
| Table | Komplexe Datentabellen | stabil | Ja, uneingeschränkt |
| Router | Typsicheres Routing | stabil | Ja (React/Solid) |
| Virtual | Sehr lange Listen | stabil | Ja, uneingeschränkt |
| Form | Formular-Management | stabil (seit v1) | Ja |
| Start | Full-Stack-Framework | Release Candidate | Mit Bedacht, neue Projekte |
| DB | Reaktiver Client-Store | Beta | Noch nicht für Kritisches |
| Pacer | Rate-Limiting u. Ä. | Beta | Eingeschränkt |
| Store, AI, Hotkeys, CLI, Intent | diverse | Alpha | Nein, nur Experimente |
Die Faustregel für den Mittelstand: Query, Table, Router und Virtual sind eine sichere Bank, und Form gehört inzwischen dazu. Bei Start lohnt sich der Blick, aber mit dem Bewusstsein, dass du auf einem frischen Fundament baust. Alles im Alpha-Stadium gehört in den Prototyp, nicht in die Produktion.
Warum das für E-Commerce und Headless Commerce relevant ist
Bis hierhin könnte der Eindruck entstehen, TanStack sei reines Entwicklerthema ohne Bezug zum Geschäft. Das Gegenteil ist der Fall, sobald du über moderne Storefronts und Headless-Architekturen nachdenkst.
Im klassischen Shopware-Setup liefert das System Frontend und Backend aus einem Guss. Sobald du aber auf eine Headless- oder Composable-Architektur setzt, also eine eigene Storefront, die über eine API vom Commerce-Backend entkoppelt ist, baust du dein Frontend selbst. Und dann tauchen exakt die Probleme auf, für die TanStack gemacht ist.
Stell dir ein typisches B2B-Kundenportal vor. Ein angemeldeter Großkunde öffnet seine Auftragsübersicht: mehrere tausend Bestellpositionen, filterbar nach Datum, Status und Lieferadresse, und der Warenkorb soll live die kundenindividuellen Staffelpreise ziehen. Genau hier verteilt sich die Arbeit auf die reifen Bibliotheken. Produktdaten, Warenkorb und Verfügbarkeiten kommen über eine API, die geladen, gecacht und synchron gehalten werden muss: das ist TanStack Query. Die langen, filterbaren Bestell- und Angebotslisten übernehmen TanStack Table für die Logik und Virtual, damit auch 5.000 Zeilen flüssig scrollen. Die mehrstufige Bestell- oder Konfigurator-Strecke mit Dutzenden validierten Feldern ist ein Fall für TanStack Form. Und die typsichere Navigation durch Kategorien, Filter und Suchparameter in der URL liefert TanStack Router.
Wenn dein Team also eine eigene Storefront auf einem Headless-Backend wie Shopware, einem Composable-Stack oder einem Framework wie MedusaJS baut, ist TanStack einer der naheliegendsten Bausteine für die Frontend-Schicht. Es ersetzt das Commerce-Backend nicht, aber es nimmt deinem Team die Arbeit ab, die sonst hausgemacht, fehleranfällig und teuer im Unterhalt wäre. Genau dieser Punkt, selbst bauen gegen erprobte Bausteine nutzen, entscheidet in Headless-Projekten oft über Budget und Zeitplan.
Der 2026er-Schwenk: gebaut auch für KI-Agenten
Eine Entwicklung ist für strategische Entscheidungen erwähnenswert. TanStack positioniert sich neuerdings ausdrücklich nicht nur für Entwickler, sondern auch für KI-Agenten, die Code schreiben. Der Gedanke dahinter ist überraschend handfest: Eine typsichere, klar strukturierte Bibliothek ist nicht nur für Menschen leichter korrekt zu benutzen, sondern auch für einen KI-Coding-Assistenten. Wo die Typen fehlen, rät das Modell und produziert Code, der erst zur Laufzeit auseinanderfliegt. Wo sie vorhanden sind, kann der Assistent sich an ihnen entlanghangeln und liegt häufiger auf Anhieb richtig.
Konkret wird das in den jüngeren Bausteinen. Die CLI bringt einen eingebauten MCP-Server mit, über den ein Agent direkt mit dem Toolkit sprechen kann. Und „Intent" liefert maschinenlesbares Wissen über eine Bibliothek direkt mit dem npm-Paket aus, damit ein Agent es automatisch findet, statt sich auf veraltetes Trainingswissen zu verlassen. Für die Tagesentscheidung ist das noch nicht ausschlaggebend, weil vieles davon Alpha-Etiketten trägt. Aber es zeigt, in welche Richtung das Projekt denkt, und das ist relevant, wenn du auf eine Technologie setzt, die in fünf Jahren noch tragen soll.
Wann TanStack passt, und wann nicht
TanStack ist kein Selbstzweck. Es passt hervorragend, wenn dein Team eine eigene, anspruchsvolle Web-Oberfläche baut, ein eigenes Designsystem pflegt und Wert auf Typsicherheit und langfristige Wartbarkeit legt. Für datenintensive Anwendungen wie Dashboards, Portale, Headless-Storefronts oder interne Tools mit großen Tabellen ist es derzeit eine der besten verfügbaren Grundlagen.
Es passt schlechter, wenn dein Team schnell eine Standardoberfläche von der Stange braucht. Der headless Ansatz bedeutet, dass jemand das Aussehen tatsächlich bauen muss. Ein Team ohne solide JavaScript- und TypeScript-Tiefe holt das volle Potenzial nicht heraus, und für eine simple Marketing-Website ist der Stack schlicht überdimensioniert. Wenn ein fertiges Komponenten-Set dich in zwei Wochen ans Ziel bringt, ist das oft der pragmatischere Weg.
Eine Sache gehört auf den Tisch, die in Marketing-Übersichten gern fehlt: Lieferketten-Sicherheit. Auch ein populäres Open-Source-Projekt ist nicht immun gegen Angriffe auf das npm-Paket-Ökosystem. Im Mai 2026 wurden im Zuge der „Mini Shai-Hulud"-Angriffswelle auch zahlreiche TanStack-Pakete kompromittiert, nach Analysen rund 84 schädliche Artefakte über etwa 42 betroffene Pakete. Das ist kein spezifischer Mangel von TanStack, sondern ein systemisches Risiko jeder Abhängigkeit aus dem npm-Ökosystem. Aber genau deshalb gehört Dependency-Hygiene mit gepinnten Versionen, Audits, Lockfiles und Monitoring zu jeder ernsthaften Einführung dazu. Wer Open-Source-Bausteine nutzt, übernimmt diese Verantwortung mit.
Fazit: Wo TanStack heute steht
TanStack ist kein Framework, das mit React konkurriert, sondern eine Werkzeugsammlung, die dein Framework um die Schichten ergänzt, die jede ernsthafte Web-Anwendung braucht. Sein Kern ist headless, typsicher, Framework-unabhängig und ohne Vendor-Lock-in, und in seinen reifen Teilen so erprobt, dass die größten Tech-Konzerne darauf bauen.
Die ehrliche Einordnung für eine Architekturentscheidung: Query, Table, Router und Virtual sind heute produktionsreif und eine ausgezeichnete Wahl, gerade für datenintensive und Headless-Commerce-Frontends. Form ist nachgezogen. Start ist die spannende Wette auf die Zukunft, aber noch jung. Der Rest ist Werkstatt, kein Fundament.
Erinnerst du dich an den Einstieg? Die Wahrscheinlichkeit ist hoch, dass ein Stück TanStack längst in deinem Code steckt. Die eigentliche Frage ist deshalb nicht, ob der Stack zu deiner Architektur passt, sondern welche der reifen Bibliotheken du als Nächstes bewusst einsetzt, statt sie aufwendig selbst nachzubauen. Der vernünftigste Einstieg ist dabei der schmalste: Fang mit TanStack Query in einem realen Projekt an. Es löst ein konkretes Problem, das jedes Team kennt, ist risikoarm und vermittelt zugleich die Denkweise, auf der der gesamte Stack beruht. Von dort aus erweiterst du Stück für Stück, oder eben nicht, je nachdem, was dein Projekt wirklich braucht. Genau diese Wahlfreiheit ist der Punkt.
Plant dein Team eine Headless-Storefront oder eine datenintensive Web-Anwendung und ist unsicher, welche Bausteine zu deinem Stack passen, lohnt sich ein nüchterner Architektur-Check, bevor die erste Zeile Code fällt.
Weiterführend bei nextlevels: