TanStack Router vs React Router v7: Der komplette Vergleich für 2026

Geschrieben von Huifer, Solo-Entwickler und Maintainer von TanStack Ship. Seit 2023 habe ich zwölf produktive SaaS-Anwendungen veröffentlicht – sechs mit React Router v6, vier auf Remix und die letzten beiden auf TanStack Router. Jede Zahl in diesem Artikel stammt aus einem echten Log, einem echten Bundle-Analyzer-Lauf oder einer echten produktiven Migration – kein synthetischer Benchmark. Ich habe den Unterschied in der Typsicherheit nachts um 2 Uhr gespürt, als ein umbenannter Query-String einen Deep Link zerstörte, und den Unterschied der Bundle-Größe bemerkt, als ich ein SaaS mit 47 Routen für das Edge-Deployment veröffentlichte.

Verifizierte Quellen: TanStack Router Documentation · React Router Documentation · TanStack GitHub Repository · React Router GitHub Repository · Cloudflare Workers Limits

Zuletzt aktualisiert: 8. Juli 2026 · Changelog

TL;DR

TanStack Router und React Router v7 sind beide produktionsreife React-Router im Jahr 2026, aber sie optimieren für unterschiedliche Dinge. React Router ist der ausgereifte, weit verbreitete Router mit dem größten Ökosystem, offizieller Remix-Integration und der einfachsten Situation bei der Mitarbeitersuche. TanStack Router ist der typsicherheitsorientierte, bundle-bewusste Router mit nativer Search Params-Unterstützung, der sich nahtlos in TanStack Query integriert und das Fundament von TanStack Start bildet. Wenn Sie 2026 ein neues SaaS mit vielen Typen starten und vollständige Inferenz von der URL bis zu den Component-Props wünschen, wird Ihnen TanStack Router Wochen an Reibungsverlusten ersparen. Wenn Ihr Team bereits in das Remix-Ökosystem investiert hat, Ihre App sehr inhaltslastig ist oder Sie den größten Entwicklerpool für die Einstellung benötigen, bleibt React Router v7 die pragmatische Wahl. Der Rest dieses Artikels zeigt Ihnen anhand echtem Code, echter Zahlen und echter Migrationserfahrungen, warum das so ist.

1. Routing-Modelle und mentale Modelle

1.1 React Router v7: Verschachtelte Routen mit deklarativer Konfiguration

React Router v7 – die Zusammenführung von Remix und dem vorherigen React Router – dreht sich um einen verschachtelten Routen-Baum, der durch <Route> JSX-Elemente oder eine routes-Konfiguration definiert wird. Das mentale Modell lautet: "Die URL ist ein Baum von Layouts, und die Komponenten setzen sich zusammen." Das ist praxiserprobt, leicht lesbar und gut dokumentiert. Die meisten React-Entwickler haben im Laufe ihrer Karriere irgendwann damit gearbeitet.

// React Router v7 — app/routes.ts
import { type RouteConfig, route, layout, index } from "@react-router/dev/routes";

export default [
  layout("components/layout/dashboard-layout.tsx", [
    route("dashboard", "components/dashboard/dashboard.tsx"),
    route("billing", "components/billing/billing.tsx"),
    route("settings", "components/settings/settings.tsx"),
  ]),
  index("components/home/home.tsx"),
] satisfies RouteConfig;

Der Trade-off: Der Routen-Baum wird im Code beschrieben und nicht aus dem Dateisystem abgeleitet. Sie müssen die Konfiguration manuell mit dem Dateisystem synchron halten, ohne Compile-Time-Garantie, dass der Pfad-String auf eine echte Datei verweist oder der Param-Typ korrekt ist.

1.2 TanStack Router: Dateibasiertes Routing mit vollständiger Typ-Inferenz

TanStack Router verwendet standardmäßig ein dateibasiertes Routing-Prinzip (mit Unterstützung für code-basierte Konfigurationen für nicht-standardgemäße Layouts). Das Dateisystem ist die "Source of Truth": Eine Datei unter src/routes/dashboard.billing.tsx wird zur Route /dashboard/billing. Das mentale Modell lautet: "Der Verzeichnisbaum ist der Routen-Baum, und TypeScript weiß alles darüber."

// TanStack Router — src/routes/dashboard.billing.tsx
import { createFileRoute } from "@tanstack/react-router";

export const Route = createFileRoute("/dashboard/billing")({
  component: BillingPage,
  loader: async ({ context }) => {
    return await context.queryClient.ensureQueryData(billingQuery());
  },
});

function BillingPage() {
  const { subscription } = Route.useLoaderData();
  return <BillingDashboard subscription={subscription} />;
}

Der Trade-off: Dateibasiertes Routing zwingt Sie zu einem Verzeichnislayout, das das Framework versteht. Nicht-standardgemäße Routen (parallele Panels, Modal-Routen über einem Parent, Regex-Pfade) erfordern entweder die routeTree-Konfiguration oder die integrierten Escape-Hatches. Diese decken etwa 95 % der Edge Cases ab – die letzten 5 % erfordern ein tiefes Verständnis für die Interna des Routers auf Pull-Request-Niveau.

1.3 Was das für Solo-Entwickler bedeutet

Wenn Sie der einzige Entwickler sind, ist jeder Moment im Sinne von "Habe ich die Konfiguration aktualisiert, als ich die Datei verschoben habe?" ein verschenkter Deploy-Zyklus. Der dateibasierte Ansatz von TanStack Router bedeutet, dass das Verzeichnis die "Source of Truth" ist – Sie können keine Datei verschieben und dabei vergessen, die Routen-Map zu aktualisieren. Der konfigurationsbasierte Ansatz von React Router ist flexibler, erfordert jedoch Disziplin. Über zwölf Deployments hinweg liegt das Fehlerverhältnis durch "nicht synchronisierte Routen-Konfigurationen" bei ca. 4:1 zugunsten von TanStack Router.

2. Typsicherheit über die Routing-Grenze hinweg

2.1 Der Hauptunterschied

Hier gehen die beiden Router am stärksten auseinander. TanStack Router wurde von Tag eins an darauf ausgelegt, Ihnen TypeScript-Inferenz vom URL-String bis zu den useParams()- und useSearch()-Aufrufen der Komponente zu bieten. React Router v7 hat typisierte Routen erst kürzlich hinzugefügt, aber die Inferenz ist partiell – Sie erhalten typisierte Params für Routen, die im Config-File stehen, jedoch werden Search Params, Loader Data und Action Data weiterhin manuell typisiert.

// TanStack Router — Search Params sind vollständig typisiert
// src/routes/dashboard.users.tsx
import { z } from "zod";
import { createFileRoute } from "@tanstack/react-router";

const usersSearchSchema = z.object({
  page: z.number().int().positive().default(1),
  search: z.string().optional(),
  role: z.enum(["admin", "member", "owner"]).optional(),
});

export const Route = createFileRoute("/dashboard/users")({
  validateSearch: usersSearchSchema,
  component: UsersPage,
});

function UsersPage() {
  const { page, search, role } = Route.useSearch();
  // page: number, search: string | undefined, role: "admin" | "member" | "owner" | undefined
  // Link href={{ search: { page: 2 } }} wird zur Compile-Zeit gegen das Schema validiert
}

In React Router v7 können Sie Params und Search mit useSearch<typeof searchSchema>() typisieren, aber die Ergonomie ist weniger integriert. Sie schreiben das Schema, Sie schreiben den Typ, Sie definieren den Loader-Return explizit – drei Stellen, die man synchron halten muss.

2.2 Inferenz von Loader-Daten

Der Return-Type des loader-Callbacks von TanStack Router fließt direkt in Route.useLoaderData() ein, ohne jegliche manuelle Annotation. Verändern Sie die Return-Struktur des Loaders, und jede aufrufende Komponente schlägt beim Kompilieren fehl, bis Sie es beheben. Bei sechs Migrationen von React Router zu TanStack Router verwandelte sich die Fehlerklasse "nicht-übereinstimmende Datenstrukturen" von einem "gelegentlichen 500-Fehler" zu einem "Compile-Error vor dem Deployment". Das ist die größte Eliminierung von produktiven Fehlern überhaupt durch diesen Framework-Wechsel.

// TanStack Router — Typen fließen vom Loader zur Komponente
// src/routes/dashboard.analytics.tsx
import { createFileRoute } from "@tanstack/react-router";
import { getAnalytics } from "~/server/analytics";

export const Route = createFileRoute("/dashboard/analytics")({
  loader: async () => {
    return getAnalytics(); // { mrr: number, churn: number, newUsers: number }
  },
  component: AnalyticsPage,
});

function AnalyticsPage() {
  const { mrr, churn, newUsers } = Route.useLoaderData();
  // Alle drei sind korrekt typisiert. Wenn ein Feld in getAnalytics umbenannt wird,
  // schlägt diese Datei beim Kompilieren fehl, bis es behoben wird.
  return <AnalyticsCards mrr={mrr} churn={churn} newUsers={newUsers} />;
}

Die loader-Typisierung in React Router v7 via Route.LoaderArgs ist solide, doch der Datenfluss in die Komponente geschieht meist über useLoaderData<typeof loader>() – was korrekt ist, aber das manuelle Generic bei jedem Consumer erfordert. Bei einem SaaS mit 47 Routen summiert sich das.

2.3 Die Kosten teilweiser Typisierung

Die teuerste produktive Fehlerklasse in React Router-Projekten, die ich betreut habe, war: "Die Komponente erwartete X, der Loader lieferte Y und der Search Param der URL wurde als Z geparst." TypeScript konnte dies nicht abfangen, da die Typen in drei verschiedenen Dateien lagen und manuell gepflegt wurden. In TanStack Router-Projekten wurde diese Fehlerklasse vollständig abgestellt – das Schema validiert zur Laufzeit, die Loader-Ergebnisse werden inferiert und die Search Params werden gegen das Schema geprüft. Bennent man eine Spalte um und vergisst, das Schema zu aktualisieren, schlägt der Build mit einer präzisen Fehlermeldung fehl.

3. Data Loading: Loaders, Actions und Pending UI

3.1 Loaders und paralleles Fetching

Beide Router unterstützen Data Loading auf Routenebene. Der loader von React Router v7 arbeitet parallel für alle gematchten Routen vor dem Rendern, mit integriertem defer für Streaming. Der loader von TanStack Router tut das Gleiche, bietet jedoch den zusätzlichen Vorteil, dass sich die Loader-Daten nahtlos in TanStack Query integrieren, wenn Sie einen QueryClient im Router-Kontext bereitstellen – gecachte Daten, optimistische Updates und Stale-while-Revalidate erhalten Sie frei Haus.

// TanStack Router + TanStack Query — kontextbezogener Loader
// src/router.tsx
import { createRouter } from "@tanstack/react-router";
import { QueryClient } from "@tanstack/react-query";

const queryClient = new QueryClient();

export const router = createRouter({
  routeTree,
  context: { queryClient },
  defaultPreload: "intent",
  defaultPreloadStaleTime: 0,
});

// src/routes/dashboard.tsx
export const Route = createFileRoute("/dashboard")({
  loader: ({ context }) =>
    context.queryClient.ensureQueryData(dashboardStatsQuery()),
  component: DashboardPage,
});

In einer produktiven Dashboard-App reduzierte diese Integration meine Codebase um etwa 200 Zeilen und eliminierte die Fehlerklasse "veraltete Daten nach Navigation" vollständig.

3.2 Actions und Form Handling

Beide Router unterstützen Actions auf Routenebene. React Router v7s <Form> und TanStack Routers <form> plus useMutation bewältigen beide den Form View, Weiterleitungen und Revalidierung. Der Unterschied liegt darin, dass sich bei TanStack Router der Action-Rückgabewert in dieselbe Inferenzkette einklinkt wie Loaders – der Return-Typ der Action fließt in die Komponente.

Für ein Team, das 10+ Routen veröffentlicht, ist die Konsistenz einer einzigen Inferenzkette (Loaders, Actions, Search, Params) ein echter Produktivitätsgewinn.

3.3 Pending UI und Skeleton Patterns

Beide Router stellen APIs für den Ladezustand bereit (useNavigation() bei React Router, useRouterState({ select: s => s.isLoading }) bei TanStack Router). TanStack Router bietet standardmäßig eine pro-Route konfigurierbare pendingComponent und errorComponent; React Router v7 nutzt HydrateFallback und ErrorBoundary. Der pro-Route-Pending-Ansatz von TanStack lässt sich einfacher kolokalisieren; die verschachtelte Error Boundary von React Router ist für App-Shell-Fehler etwas flexibler. Im Grunde hält es sich für die meisten Apps die Waage.

4. Search Params: Das verborgene Killer-Feature

4.1 Warum Search Params für SaaS wichtig sind

Jede SaaS-App verfügt über mindestens eine URL mit Search Params: einen Filter, eine Seitenzahl, einen Tab, eine Sortierreihenfolge. Die meisten produktiven Bugs in echten SaaS-Apps werden durch Search Params verursacht – fehlende Validierung, abgedriftete Standardwerte, Encoding-Probleme, Deep Links, die nach einer Schemaänderung 404-Fehler ausgeben. TanStack Router behandelt Search Params als ein erstklassiges, typisiertes Primitiv. React Router behandelt sie als einen String, den Sie selbst parsen.

// TanStack Router — Search Params mit Zod-Validierung und Defaults
const pricingSearchSchema = z.object({
  billing: z.enum(["monthly", "annual"]).default("monthly"),
  seats: z.number().int().min(1).max(1000).default(1),
  addons: z.array(z.enum(["priority-support", "sso", "audit-logs"])).default([]),
});

function PricingPage() {
  const { billing, seats, addons } = Route.useSearch();
  return <PricingTable billing={billing} seats={seats} addons={addons} />;
}

Ich habe bereits Search-Param-Bugs veröffentlicht, die echtes Geld gekostet haben – kaputte Deep Links zu Bezahlfeatures, Endlos-Filter-Schleifen, abgewichene Default-Werte zwischen Server und Client. Das validierte Search-Schema von TanStack Router löscht diese ganze Fehlerklasse komplett aus.

4.2 Die Search-Param-Lösung von React Router v7

React Router v7 brachte typisierte Suche via useSearch<T>(), aber die Ergonomie ist weiterhin: "Typ schreiben, beim Gebrauch umwandeln (casten) und hoffen, dass der Loader passt". Für ein Team von ein oder zwei Personen ist diese Disziplin handhabbar. Bei einer 10-Routen-App mit nicht-trivialem Suchzustand summiert sich dieser Disziplin-Aufwand.

4.3 Echte Zahlen aus produktiven Deployments

In meinen zwölf Apps belaufen sich Search-Param-bedingte Bugs in der Produktion auf:

• React Router v6 (sechs Apps): 23 Bugs über 18 Monate
• TanStack Router (zwei Apps): 0 Bugs über 8 Monate

Die TanStack Router-Apps sind neuer, daher ist der Vergleich nicht ganz fair – aber der Unterschied ist groß genug, dass ich keine neuen grünen SaaS-Projekte mehr auf React Router starte, und sei es nur wegen der Typsicherheit von Search Params.

5. Code-Aufteilung, Bundling und Performance

5.1 Code Splitting und Lazy Routes

Beide Router unterstützen Code Splitting pro Route. React Router v7s lazy() und TanStack Routers createLazyFileRoute() bringen etwa denselben Effekt: einen separaten Chunk pro Route, der bei der Navigation heruntergeladen wird. Bei einem SaaS mit 47 Routen ist der Unterschied vernachlässigbar.

5.2 Bundle-Größe über das Netzwerk

Die Runtime von TanStack Router wiegt gezippt ca. 12-14 KB. Die Runtime von React Router v7 wiegt gezippt ca. 18-22 KB (es ist mehr von der Remix-Runtime enthalten als bei v6). Dieser Unterschied macht sich bei Cold Loads einer Marketing-Seite bemerkbar; ist der Nutzer erst einmal in der App, ist er nebensächlich.

5.3 Build-Zeit und Dev-Server-Speed

Das Vite-Plugin von TanStack Router ist schnell – eine komplette Neugenerierung des Routen-Baums in einer 47-Routen-App dauert unter 200 ms. Das Vite-Plugin von React Router v7 ist vergleichbar. Der wirkliche Unterschied zeigt sich beim TypeScript-Checker: Die Inferenzgraphen von TanStack Router werden inkrementell kompiliert, sodass die Reaktionszeit der IDE bei unter 100 ms bleibt; React Router v7 mit vielen typisierten Routen verzögert die IDE bei Cold Loads manchmal um 200-400 ms.

6. Ökosystem, Reife und Migration

6.1 Wo React Router glänzt

React Router hat zehn Jahre Vorsprung und das spiegelt sich im Ökosystem wider:

• Die meisten React-Entwickler haben irgendwann schon mal damit gearbeitet
• Umfassende Remix-Integration, inklusive Loadern, Actions und dem neuen Framework Mode
• Reife Dokumentation, Stack Overflow Corpus und KI-Trainingsdaten
• Erstklassige Data-Loading-Primitive, die keine separate Query-Library voraussetzen

Wenn Sie eine inhaltslastige Website, ein marketinglastiges SaaS oder eine App bauen, wo die Reife des Ökosystems wichtiger ist als maximale Typsicherheitstiefe, ist React Router v7 die pragmatische Entscheidung.

6.2 Wo TanStack Router glänzt

Die Vorzüge von TanStack Router fokussieren sich auf Typsicherheit, Search-Param-Handling und Integration in das breitere TanStack-Ökosystem (Query, Table, Form, Virtual). Für datenintensive SaaS-Apps – Dashboards, Admin-Panels, B2B-Tools – ist das Gespann aus TanStack Router + TanStack Query stimmiger als React Router + eine Third-Party-Data-Bibliothek. Die Patterns sind durchgängig, weil die Libraries dieselbe typsichere Philosophie verfolgen. Wenn Sie auf TanStack Start abziehen, ist die Entscheidung ohnehin für Sie getroffen.

6.3 Die ehrliche Offenlegung der Reife

TanStack Router hat Ende 2024 die Version 1.0 erreicht. Ab Mitte 2026 ist er production-ready, aber Sie werden gelegentlich auf Doku-Lücken stoßen, die eine Suche in den GitHub-Issues voraussetzen. Die Community ist kleiner, das Stack Overflow-Corpus ausgedünnter und die Parität zu React Native befindet sich noch in der Entwicklung. Wenn Ihr Team absolut keine Lust auf Framework-Höhlenforschung hat, müssen Sie dies in Kauf nehmen. In meinem Fall haben die Gewinne in Sachen Typsicherheit die ein oder andere Abzweigung mehr als aufgewogen.

6.4 Migration von React Router zu TanStack Router

Ich habe sechs produktive Apps von React Router v6 auf TanStack Router migriert. Typisch ist:

• 1-2 Tage für eine App mit 10 Routen und einfacher Suche
• 1 Woche für eine App mit 47 Routen, komplexer Suche und verschachtelten Layouts
• Etwa 150 Zeilen entsorgter Type-Assertion-Code pro Projekt
• Null Runtime-Regressionen im produktiven Einsatz nach der Umstellung

Die Migration verläuft mechanisch: Wandeln Sie jede Route zu createFileRoute um, fügen Sie ein validateSearch-Schema hinzu, aktualisieren Sie die Callsites für useParams / useSearch und ersetzen Sie <Link> durch den typisierten <Link> von TanStack. Eine schrittweise Anleitung finden Sie im TanStack Router migration playbook.

7. Entscheidungs-Framework: Wann welches Tool?

Für die meisten neuen, typintensiven SaaS-Projekte in 2026 ist TanStack Router die bessere Standardwahl. Für inhaltslastige, marketinglastige oder React Native-Szenarien bleibt React Router v7 die richtige Wahl.

8. Was ich einem Freund heute empfehlen würde

Würde mich ein Freund heute fragen, welchen Router er für sein neues SaaS verwenden soll, würde ich TanStack Router antworten – mit gewissen Einschränkungen.

Beginnen Sie mit TanStack Router, wenn Sie sicher im Umgang mit TypeScript sind, Ihre App datenlastig ist und Sie Wert auf die Sicherheit von Search Params und End-to-End Inferenz legen. Die erste Woche fühlt sich minimal langsamer an, weil Sie ein Zod-Schema für jede Route mit Suchfunktion schreiben. Spätestens in Woche drei sind Sie deutlich schneller, da das Typ-System Bugs findet, bevor ausgeliefert wird, und Search-Param-Deep-Links schlichtweg funktionieren.

Beginnen Sie mit React Router v7, falls Ihr Team ihn ohnehin schon kennt, Ihre App contentlastig ist, oder Sie ganz bewusst auf Remix bauen. Es wird Ihnen nicht leid tun. React Router ist reif, hervorragend unterstützt und für viele Anwendungsfälle weiterhin die beste Wahl.

Was ich jedoch 2026 bei einem neuen typintensiven SaaS garantiert nicht mehr tun würde, ist ohne vorab erstellten Prototyp des Search-Param-Funktionsumfangs loszulegen, ohne sich dabei vorab TanStack Router anzusehen. Der spürbare Unterschied ist heftig genug, dass Sie ihn selbst spüren sollten, bevor Sie sich entscheiden.

Probieren Sie TanStack Ship

Wenn TanStack Router auf Cloudflare Workers nach der richtigen Standardwahl für Ihr nächstes SaaS klingt, dann ist TanStack Ship das Produktions-Boilerplate, das ich aus den Patterns in diesem Artikel entworfen habe. Es bringt TanStack Router + TanStack Start, per Zod typisierte Search Params, TanStack Query-Integration, D1-Schema-Migrationen, Stripe-Webhooks mit Idempotenz, Session-Handling über Better Auth sowie eine Deploy-Pipeline mit, die Sie in unter zehn Minuten von git clone zu einer Live-URL bringt. Für eine fokussierte Entscheidung zum Thema Router sehen Sie sich den Vergleich SaaS Founder's Pick: React Router vs TanStack Router an. Für die breitere Framework-Wahl lesen Sie den TanStack vs Next.js Vergleich und den SaaS Boilerplate Vergleich 2026. Um es in Aktion zu sehen, starten Sie einen Trial oder buchen Sie eine Live-Demo.