TanStack Start ist noch Release Candidate. Ein Team hat trotzdem ein laufendes SaaS dorthin migriert.

Ein Framework vor der 1.0 zu übernehmen ist eine Wette: dass das Team dahinter hält, was es versprochen hat, und dass die eigene Codebasis nichts von dem braucht, was in der Lücke zwischen Release Candidate und Stable noch kommt. Die meisten Vergleiche zwischen einem Pre-1.0-Framework und einem etablierten bleiben hypothetisch — eine Todo-App, zweimal gebaut und benchmarkt. Was dabei fehlt, ist der Teil, der wirklich zählt: was passiert, wenn jemand diese Wette an einem zahlenden Produkt eingeht.

Ein dokumentierter Fall zeigt genau das. Melvyn Malherbe, der die Online-Lernplattform Codeline baut, hat deren echte Produktions-App — Checkout, Admin-Bereich, Nutzerkonten, alles — von Next.js zu TanStack Start migriert und die Migration im Detail in einem Video gezeigt. Der Pull Request fügte rund 100.000 Zeilen hinzu und entfernte etwa 129.000. Das Framework, bei dem er gelandet ist, trägt auf seiner eigenen Startseite immer noch das Label Release Candidate, nicht 1.0 — er hat ein laufendes Geschäft auf Software gesetzt, die die eigenen Maintainer selbst als noch nicht ganz fertig bezeichnen.

Diese eine Migration ist kein Urteil darüber, welches Framework besser ist. Es ist ein konkreter, dokumentierter Bericht darüber, was eine echte Migration gekostet und gebracht hat — inklusive der Details, die eine Marketingseite weggelassen hätte —, hier verwendet, um eine größere Frage zu illustrieren: was “noch RC” für jeden bedeuten sollte, der überlegt, ihm zu folgen.

Was TanStack Start eigentlich ist

TanStack Start ist ein Full-Stack-React-Framework, aufgebaut auf TanStack Router, der Routing-Bibliothek, die seit 2024 stabil in Produktion läuft. Wo Next.js server-first ist — der Server entscheidet standardmäßig, wie eine Seite gerendert wird —, ist TanStack Start client-first mit angehängten Server-Bausteinen: vollständiges serverseitiges Rendering, Streaming, Server-Funktionen und Server-Routen, alles aufgebaut auf demselben typisierten Routenbaum, den Router bereits liefert. Die Typprüfung greift bei Routen, URL-Parametern und Suchparametern schon zur Compile-Zeit, nicht nur über ein Editor-Plugin.

Die offizielle Seite von TanStack Start, die derzeit das Badge “RC” zeigt und 18.055.219 wöchentliche Downloads sowie 14.805 GitHub-Sterne ausweist.

Das Framework brachte seinen Release Candidate am 23. September 2025 heraus, wobei das TanStack-Team erklärte, man wolle “die 1.0 kurz nach dem Sammeln des RC-Feedbacks schneiden”. Zum Zeitpunkt dieses Textes ist das noch nicht geschehen: Die offizielle Dokumentation trägt weiterhin das RC-Badge und empfiehlt, Abhängigkeitsversionen festzulegen statt auf einer breiten Range mitzuschwimmen. Eine echte Lücke, die man vor der Entscheidung kennen sollte: React Server Components, die Funktion, um die Next.js einen Großteil seiner jüngeren Identität aufgebaut hat, werden noch nicht unterstützt. Das TanStack-Team listet sie als aktiv in Entwicklung, geplant als nicht brechende Ergänzung, sobald sie fertig ist.

Nichts davon macht es zu einem Spielzeug. Vierzehn Unternehmen, darunter Cloudflare, Netlify, Prisma, Convex und Clerk, sind als offizielle Ökosystem-Partner gelistet, die Integrationen dafür bauen. Das ist eine ernstzunehmende Liste für Pre-1.0-Software, und sie ist mit ein Grund, warum eine funktionierende Plattform wie Codeline überhaupt darauf migrieren konnte.

Die Migration, die tatsächlich stattfand

Codeline ist kein Demo-Repo. Es ist Malherbes kommerzielles Produkt: Kurs-Checkout, ein Admin-Dashboard, Nutzerkontenverwaltung, mehrere hundert Seiten laufender Inhalte. Die Migration selbst, als Pull Request #315 verfolgt, lief größtenteils über einen KI-Coding-Agenten (Codex) mit einem eigens dafür gebauten Skill, migrate-nextjs-to-tanstack, und kostete ihn nach eigenen Angaben mehrere hundert Dollar an Modell-Tokens. Eine Migration dieser Größe, die größtenteils von einem Agenten erledigt wird, an einem zahlenden Produkt, ist selbst der ungewöhnlichere Teil dieser Geschichte — die Framework-Wahl ist fast zweitrangig gegenüber der Tatsache, dass eine KI den Löwenanteil der Arbeit am Code eines echten Geschäfts übernommen hat.

Er nennt drei Gründe für den Wechsel, und die zwei stärksten kommen mit Zahlen, die er selbst gemessen hat, nicht mit Zahlen, die ihm erzählt wurden.

Die Build-Zeit hat sich ungefähr halbiert. Über Dutzende Deployments liefen seine Next.js-Builds am schnellen Ende bei 3 Minuten 17 Sekunden und am langsamen Ende bei 3 Minuten 47 Sekunden, im Schnitt rund 3 Minuten 30. Bei TanStack Start lag dieselbe Spanne bei 1 Minute 9 Sekunden bis 1 Minute 35 Sekunden, im Schnitt etwa 1 Minute 20. Das ist ein konstanter Unterschied von über 2 Minuten bei jedem Deployment — genau die Art von Lücke, die am meisten zählt, wenn man am wenigsten will, dass sie zählt: bei einem Produktionsvorfall, bei dem jemand darauf wartet, dass ein Fix rausgeht.

Die Navigation fühlte sich unter einer langsamen Verbindung anders an, nicht nur unter einer schnellen. Malherbe demonstrierte beide Apps nebeneinander mit Netzwerk-Throttling, das 3G simulierte. Next.js zeigte die bekannte Kaskade: ein Platzhalter, dann ein Loader, dann ein Re-Render, sobald Daten ankamen. TanStack Start, mit dem Prefetching von TanStack Router und gezielten Skeletons für das, was tatsächlich lädt, zeigte sofort das passende Skeleton, ohne unnötige Ladezustände übereinanderzustapeln. Das ist ein subjektiver Vergleich aus einer einzigen Demo, kein unabhängiger Benchmark — aber es ist eine Demo am eigenen Produkt, nicht an einem sorgfältig ausgewählten Beispiel.

Das Argument, das ihm am wichtigsten war, war nicht die Geschwindigkeit

Malherbe machte klar: Sein Hauptgrund für den Wechsel waren weder die Build-Zeiten noch das Navigationsgefühl. Es ist, dass TanStack Start für einen KI-Coding-Agenten leichter korrekt zu bedienen ist, weil seine API deklarativ ist und die Belange jeder Route in einem Block bündelt:

export const Route = createFileRoute('/path')({
  beforeLoad: checkAuth,             // Middleware
  validateSearch: searchSchema,      // typsichere Suchparameter
  loaderDeps: ({ search }) => search,
  loader: async ({ deps }) => fetchData(deps),
  pendingComponent: SkeletonUI,      // Lade-UI
  component: PageComponent,          // Rendering
  head: () => ({ meta: [...] }),     // SEO
})

Zum Vergleich das Vokabular, das ein Next.js-Projekt angesammelt hat: use server, use client, Server Actions, die mitten in ihrem eigenen Rollout umbenannt wurden, eine Aufteilung in Page- und App-Directory, Middleware- und Proxy-Verhalten, die sich genug überschneiden, um zu verwirren, welcher Name gilt, und use cache, noch später obendrauf geschichtet. Keine dieser Entscheidungen ist für sich genommen schlecht — die meisten gehen darauf zurück, dass Next.js echte Probleme löste, während sich Reacts eigenes Modell um es herum weiterentwickelte. Aber ein Agent, der Code generiert, muss wissen, aus welcher Terminologie-Ära eine gegebene Codebasis stammt, und Malherbes Aussage ist, dass sein Agent das auf dem alten Stack ständig falsch einschätzte und es auf dem neuen selten tut.

Diese Aussage bleibt sein persönlicher Eindruck aus einer einzigen Migration, kein gemessener Benchmark, und sollte so gelesen werden. Es ist aber auch keine Aussage, die man einfach abtun sollte: Wie KI-freundlich die API-Oberfläche eines Frameworks ist, ist eine reale, weitgehend ungemessene Variable, die kaum eine Rolle spielte, solange Menschen den gesamten Routencode von Hand schrieben.

Was die Migration ihn gekostet hat

Die One-Shot-Version dieser Geschichte würde bei den obigen Zahlen aufhören. Sollte sie nicht. Die KI-getriebene Migration produzierte echte Bugs, die im Nachhinein korrigiert werden mussten: ein falsch platzierter Benachrichtigungsbutton und kaputte Avatare sind zwei, die er konkret erwähnte. Ein Agent, der 100.000 Zeilen eines laufenden Produkts verschiebt, ist kein sauberer, stiller Prozess — es ist ein Prozess, bei dem ein Mensch das Ergebnis prüfen muss, bevor es live geht, genau wie bei jedem großen Refactor, egal wer ihn geschrieben hat.

Die andere ehrliche Kostenseite steckt in der Versionsnummer des Frameworks selbst. Das Ökosystem von TanStack Start — Plugins, Anleitungen von Dritten, Stack-Overflow-Antworten — ist deutlich dünner als das von Next.js, weil Next.js Jahre an breitem Einsatz hatte, um das aufzubauen. Ein Pre-1.0-Framework zu übernehmen ist eine Wette: dass die verbleibenden API-Änderungen vor der 1.0 klein bleiben und dass sein Ökosystem schnell genug wächst, um aufzuholen. Codeline ist Malherbes eigenes Produkt, also trägt er dieses Risiko direkt selbst. Ein Team, das das Produkt eines Kunden ausliefert, oder eine Plattform mit einem Compliance-Freigabeprozess, geht mit derselben Entscheidung ein anderes Risiko ein.

Die offizielle Startseite von Next.js, dem Framework, von dem sich Codeline entfernt hat.

Worauf das eigentlich hinausläuft

Worauf das eigentlich hinausläuft.

Das ist eine einzige Migration, dokumentiert von der Person, die sie durchgeführt hat — kein Branchenkonsens und kein kontrollierter Benchmark. Behandle die Build-Zeit-Zahlen und die Aussage zur KI-Freundlichkeit als echte Daten aus einem echten System, nicht als allgemeines Gesetz über eines der beiden Frameworks. Was sich daraus ablesen lässt: TanStack Start ist inzwischen reif genug, und hat genug Rückhalt im Ökosystem, dass mindestens ein laufendes kommerzielles Produkt darauf läuft, ohne zusammenzubrechen. Ob das ein grünes Licht für das eigene Projekt ist, hängt davon ab, wie dringend man React Server Components heute braucht, wie viel Produktionssicherheit das eigene Projekt verlangt, bevor seine Abhängigkeiten die 1.0 erreichen, und wie viel des eigenen Routencodes tatsächlich von einem Agenten statt von einem Menschen geschrieben wird.

FAQ

Ist TanStack Start produktionsreif? Das hängt von der eigenen Risikobereitschaft ab, nicht von einem einfachen Ja oder Nein. Es trägt auf der eigenen Seite das Label Release Candidate, nicht 1.0, und das TanStack-Team empfiehlt, Abhängigkeitsversionen festzulegen statt einer breiten Range zu folgen. Mindestens ein echtes kommerzielles Produkt, Codeline, läuft in Produktion darauf — das zeigt, dass es in dieser Größenordnung nutzbar ist, nicht, dass die verbleibenden Pre-1.0-Änderungen risikofrei sind.

Unterstützt TanStack Start React Server Components? Noch nicht. Das TanStack-Team führt sie als aktiv in Entwicklung, geplant als nicht brechende Ergänzung, sobald sie fertig sind. Wenn das eigene Projekt heute auf RSC angewiesen ist, ist das aktuell ein Grund, bei Next.js zu bleiben.

Ist TanStack Start tatsächlich schneller im Build als Next.js? Bei einer dokumentierten Migration ja, und zwar konstant: rund 3 Minuten 30 im Schnitt bei Next.js gegenüber rund 1 Minute 20 bei TanStack Start, über Dutzende Deployments derselben Anwendung. Das sind die echten Zahlen eines einzelnen Teams, kein unabhängiger, kontrollierter Benchmark über viele Projekte hinweg — als starkes Signal zu lesen, nicht als garantiertes Ergebnis für jede Codebasis.

Warum sollten KI-Coding-Agenten mit TanStack Start besser arbeiten? Die Aussage aus derselben Migration ist, dass TanStack Start Logik, Middleware, Ladezustand und Datenabruf jeder Route in einem deklarativ benannten Objekt bündelt, während Next.js mehrere sich überschneidende oder umbenannte Konzepte angesammelt hat (Server Actions, use server, use client, Middleware versus Proxy), während sich Reacts Modell darunter veränderte. Ein Agent muss richtig erraten, aus welcher Terminologie-Ära einer Next.js-Codebasis er gerade arbeitet; die API von TanStack Start lässt ihm weniger Raum zum Falschraten. Das ist ein berichteter Eindruck aus einer Migration, kein gemessener, reproduzierbarer Benchmark.

Sollte man eine bestehende Next.js-App auf TanStack Start migrieren? Nur, wenn man bereit ist, das Pre-1.0-Risiko zu akzeptieren, und einen konkreten Grund hat: einen stark KI-gestützten Entwicklungsworkflow, den Bedarf an schnelleren Builds bei einer großen App, oder ein Greenfield-Projekt, bei dem das dünnere Ökosystem weniger kostet. Wenn das eigene Projekt jetzt React Server Components braucht oder volle Produktionssicherheit verlangt, bevor sein Kern-Framework die 1.0 erreicht, bleibt Next.js die sicherere Standardwahl.