Sollten Sie React 2026 entfernen? Ein Playbook zur Frontend‑Vereinfachung für CTOs

React überall ist kein Naturgesetz. Es war ein kluger Default für ein Jahrzehnt Web‑UX, aber das heißt nicht, dass Ihr SaaS 2026 eine einzige, permanent hydrierende App sein muss. Die jüngste Welle von Teams, die React zugunsten von htmx und servergerenderten MPAs herausreißen, ist keine Nostalgie; sie ist eine nüchterne Abrechnung von Komplexität und Kosten. Ein HN‑Post, der gerade die Runde macht, beschreibt ein Unternehmen, das React entfernt und htmx für Interaktivität einsetzt. Das ist ein Schuss vor den Bug für alle, die On‑Call‑Kosten für Hydration‑Bugs zahlen, ohne eine entsprechende UX zu shippen.

Was hat sich geändert, seit wir alle auf SPA gesetzt haben?

• Der Browser wurde schnell, Ihre App ist CPU‑gebunden. Moderne Engines und HTTP/2+ machen Mehrseiten‑Navigationen günstig. Ihr eigentlicher Flaschenhals ist das Parsen von JS, Hydration und Main‑Thread‑Thrash.
• Der Großteil der B2B‑Oberfläche ist weiterhin CRUD. Wenn 70–80% Ihrer Screens aus Formularen, Tabellen und Pagination bestehen, reicht eine 14‑KB‑Library, die HTML‑Fragmente tauscht. React + react‑dom + Router + Daten‑Layer landen typischerweise bei 150–300 KB (gzipped) – noch bevor Ihr eigener Code hinzukommt.
• Core Web Vitals haben Performance monetarisiert. Sie spüren es in SEO und Aktivierungs‑Funnels. Hydration zu streichen ist für viele Teams der schnellste verbliebene INP/LCP‑Hebel.
• Server‑Frameworks sind gereift. Rails 7 + Hotwire, Django + htmx, Phoenix LiveView, Laravel Livewire, Astro Islands — das ist nicht 2013. MPA + selektive Islands ist ein erstklassiger Pfad.

React ist großartig — bis es das nicht mehr ist

React bleibt eine exzellente Wahl, wenn Ihr Produkt eine zustandslastige, kollaborative Arbeitsfläche (Canvas) ist (denken Sie an Figma, Notions Block‑Editor, tief interaktive Dashboards) oder Offline‑First‑Garantien benötigt. Aber für Datenerfassungs‑Workflows, Admin‑Oberflächen, Marketing-/User‑Lifecycle‑Flows, Wissensbasen, Einstellungsseiten zahlen Sie eine permanente Plattformsteuer für ein Problem, das Sie nicht haben.

Wenn Sie vermuten, dass Sie in diese Kategorie fallen, hören Sie auf, über Geschmack zu diskutieren, und rechnen Sie nach.

Das Entscheidungsframework für CTOs: Sollten Sie React entfernen?

Bewerten Sie Ihr Produkt auf fünf Achsen (0–5 je Achse)

1. Interaktivitätsdichte. Wie viele gleichzeitige zustandsbehaftete Controls pro View? 0 = einfache Formulare/Tabellen, 5 = verschachtelte, draggable Komponenten, Editoren, synchronisierte Widgets. Schwelle: Wenn durchschnittliche Screens ≤ 2, dann Score ≤ 2.
2. Echtzeit‑Kollaboration. Multi‑Cursor, Präsenz, Konfliktauflösung. 0 = keine, 5 = zentral fürs Produkt. Schwelle: Alles ≥ 3 hält Sie für diese Oberfläche im SPA‑Land.
3. Offline/Background‑Sync. Muss es bei wackeliger Konnektivität funktionieren? 0 = nein, 5 = ja, mit robuster lokalem State. Offline ≥ 3 spricht für SPA oder native.
4. Navigationsmodell. Stehen Views für sich mit klaren URLs, oder ist es eine große Szene? 0 = MPA‑freundlich, 5 = SPA‑zentriert mit geteiltem Szenen‑State.
5. Regulatorischer/SEO‑Druck. Crawlability, deterministisches Rendern und Privacy (keine PII des Clients in JS). 0 = niedrig, 5 = hoch. Hohe Werte begünstigen SSR/MPA.

Heuristik: Wenn Ihr gewichteter Mittelwert ≤ 2,5 liegt, werden Sie mit einem MPA + Progressive‑Enhancement‑Stack wahrscheinlich schneller shippen, weniger crashen und besser scoren. Bei ≥ 3,5 behalten Sie React dort, wo es echten Hebel bringt. Wenn Sie dazwischen liegen, mischen Sie: eine MPA‑Shell mit ein paar React‑ oder Web‑Component‑Islands.

Der Business‑Case: Wofür Sie nicht mehr zahlen

• Bundle‑ und Hydration‑Steuer. htmx ist ~14 KB (gzipped). Ein typischer React‑Stack (react + react‑dom + router + query + Ihr Glue) landet bei 150–300 KB (gzipped). 200 KB zu trimmen und Hydration zu überspringen bringt regelmäßig 15–30% bessere LCP und spürbare INP‑Gewinne auf Mittelklasse‑Geräten.
• State‑Bugs und On‑Call‑Zeit. Hydration‑Mismatches, abgestandene Caches, Effekt‑Loops — wenn Ihre Incident‑Rotationen diese im Schlaf kennen, finanzieren Sie eine Rube‑Goldberg‑Maschine. Teams, die wir von SPA‑Mustern wegbewegt haben, reduzierten die UI‑Incident‑Last in drei Monaten routinemäßig um 20–40%.
• Bremsklotz für Entwickler‑Durchsatz. Einen CRUD‑Flow in React zu shippen bedeutet oft, dasselbe Schema dreimal zu schreiben (Server, Client, Validator) und State durch Query/Mutation‑Layer zu fädeln. Mit SSR + htmx rendern Sie einmal, werten bei Bedarf progressiv auf und stützen sich auf bewährte Server‑Validierungen und Transaktionen.

Architekturen, die 2026 gewinnen

1) MPA + htmx (oder Turbo) + Sprinkles

Behalten Sie Ihr Server‑Framework im Fahrersitz. Rendern Sie HTML; tauschen Sie Fragmente via htmx; fügen Sie kleine alpine.js‑ oder Vanilla‑Sprinkles für lokalen UI‑State hinzu. Ihr mentales Modell ist geradlinig: Die URL mappt auf eine Server‑Action, die HTML zurückgibt. Progressive Enhancement deckt 80% der Interaktivität ab — ohne eine vollständige Client‑State‑Laufzeit.

2) MPA + Islands

Nutzen Sie ein Islands‑Framework (Astro, Marko, Qwik), um 90% HTML zu shippen und diskrete interaktive Komponenten bei Bedarf zu wecken. Für komplexe Widgets — Data Grid mit Virtualisierung, WYSIWYG‑Editor — mounten Sie eine React/Vue/Svelte‑Island in einer ansonsten auf dem Server gerenderten Seite. Sie behalten React dort, wo es sich bezahlt macht.

3) LiveView‑ähnliches SSR über WebSockets

Phoenix LiveView und ähnliche Muster lassen den Server den State besitzen, während Diffs zum Client gepusht werden. Dieses Modell räumt bei einer breiten Palette von Back‑Office‑Tools und Dashboards mit minimalem Client‑JS, starken Sicherheitsgrenzen und exzellenter Performance ab.

Risiken und Trade‑offs (tun Sie nicht so, als gäbe es keine)

• Talentpool und Momentum. React hat den größten Kandidatenpool und das größte Ökosystem. htmx und LiveView sind einfacher, aber seltener in Lebensläufen. Gegenmaßnahme: Qualifizieren Sie ein Nearshore‑Pod, um Patterns zu säen, und pairen Sie 8–12 Wochen mit Ihrem Kernteam.
• Komponenten‑Ökosystem. Sie werden React‑first‑Komponenten vermissen. Planen Sie mit Web Components, Headless‑UI oder bauen Sie die wenigen hochwertigen Widgets einmal als Islands.
• Erwartungen an Client‑seitiges Routing. SPA‑Transitions können sich flotter anfühlen. Nutzen Sie servergetriebenes Preloading, Alternativen zu HTTP/2‑Push und partielle Swaps, um 95% des Gefühls mit 5% des Codes zu erreichen.
• Feature Flags und A/B‑Infra. Wenn Ihr Experimentier‑Tooling JS‑first ist, brauchen Sie Server‑Varianten und deterministisches Rendern. Netto positiv für Observability, aber etwas Plumbing‑Arbeit vorab.

Migrieren, ohne die Firma neu zu schreiben

Vollständige Rewrites scheitern. Wenden Sie stattdessen das Strangler‑Pattern auf die SPA an.

Phase 0: Den Schmerz messen

• Heute messen. Core Web Vitals pro Pfad, JS‑Bytes pro Route, Crash‑Rate, Anzahl Hydration‑Fehler, p95 INP auf Mittelklasse‑Android.
• Oberflächen taggen. Labeln Sie Routen als CRUD, Marketing, Einstellungen, Editor, Dashboard etc. Sie werden sie nicht alle gleich migrieren.

Phase 1: Beweisen Sie es auf risikoarmen Oberflächen (2–4 Wochen)

• Marketing‑ und Auth‑Flows. Verschieben Sie Login, Signup, Passwort‑Reset, E‑Mail‑Verifizierung zu SSR. Diese profitieren ohnehin von deterministischem Rendern und SEO.
• Einstellungen und Profile. Ersetzen Sie Client‑State durch Server‑Formulare und htmx‑Fragment‑Swaps. Erwarten Sie sofortige Bundle‑Gewinne und weniger Edge‑Case‑Bugs.
• Nochmals messen. Wenn Sie auf diesen Pfaden keine zweistelligen LCP/INP‑Verbesserungen und weniger UI‑Incidents sehen, stoppen Sie. Ihre SPA könnte gerechtfertigt sein.

Phase 2: Eine servergerenderte Shell ausschneiden (4–8 Wochen)

• Route für Route, verschieben Sie Navigation, Header, Footer und die meisten Seiten zu Server Rendering. Halten Sie Ihre komplexen Widgets als React‑Islands innerhalb dieser Seiten montiert. Das liefert 80% der Benefits, ohne Ihre härteste UI anzutasten.
• Eine Fragment‑API einführen. Standardisieren Sie Endpunkte, die partielle HTMLs für Listen, Pagination und Modal‑Inhalte zurückgeben. Diese werden Ihre neuen UI‑Primitiven.
• Geteilte Validierungen. Zentralisieren Sie Schema und Validierung auf dem Server. Der Client macht Progressive Enhancement, nicht Business‑Logik.

Phase 3: Über das Schicksal Ihrer komplexen Widgets entscheiden (8–16 Wochen)

• React dort behalten, wo es sich lohnt. Editoren, schwere Data Grids, Echtzeit‑Kollaboration: Lassen Sie sie als Islands. Nutzen Sie Lazy Hydration und shippen Sie Code nur dort, wo er gebraucht wird.
• Vereinfachen, wo möglich. Viele „komplexe“ Widgets sind kein Kernwert. Eine seitenweise Tabelle und ein Modal‑Formular können maßgeschneiderte Grid+Inline‑Edit‑Kombos ersetzen, ohne die UX zu verschlechtern.

Governance und Performance‑Gates

• Budgets setzen. Pro‑Route‑JS‑Budget (z. B. ≤ 50 KB gz für Non‑Island‑Seiten), p75‑INP‑Schwellen, Fehlerbudgets für Hydration‑Mismatches (Ziel: null auf MPA‑Routen).
• Codeowners und ADRs. Jede neue SPA‑Oberfläche erfordert ein Architecture Decision Record mit expliziter Begründung entlang der fünf Achsen. Default ist MPA + Enhancement.

Security, Privacy und Compliance werden einfacher

• Weniger PII auf dem Client. Serverseitiges Rendering bedeutet, dass Sie sensible Felder erst dann in den Browser schicken, wenn es absolut nötig ist. Das verkleinert Ihre Daten‑Angriffsfläche.
• Weniger querschnittliche Seiteneffekte. Keine ausufernden Client‑Caches und Global Stores, die State über Mandanten oder Sessions leaken.
• Deterministisches Audit. Was der Server gerendert hat, ist das, was der Benutzer gesehen hat. Das zählt für regulierte Flows und Legal Holds.

Echte Beispiele zur Kalibrierung Ihres Bauchgefühls

• Basecamp/HEY hat Hotwire/Turbo populär gemacht, um komplexe SaaS ohne SPA‑Runtime zu betreiben, und berichtet über große Performance‑ und Komplexitätsgewinne.
• GitHub nutzt seit Langem PJAX/Turbo‑ähnliche Techniken mit servergerendertem HTML und Sprinkles. Niemand nennt GitHub langsam.
• Django + htmx Teams shippen admin‑lastige Produkte in Wochen statt Monaten, gestützt auf Server‑Formulare, Transaktionen und optimistische UI via Fragment‑Swaps.

Das sind keine Spielzeug‑Apps. Sie beweisen: Wenn Ihr Value Prop Workflow und Datenkorrektheit ist — und nicht eine pixelperfekte Multiplayer‑Canvas — funktioniert Server‑first und skaliert.

Wie wir das als Nearshore‑Engagement fahren

Wenn Sie nicht die Kapazität haben, diesen Kampf allein zu führen, starten Sie ihn mit einem Pod, das dieses Muster wiederholt ausgeliefert hat. Unsere Brazil‑based Teams arbeiten in Ihren Zeiten (6–8 Stunden Overlap U.S. Time) und beginnen mit einem Zwei‑Sprint‑Proof auf risikoarmen Flows. Wir kodifizieren Patterns, bauen Ihre Fragment‑API und hinterlassen Ihnen Budgets, Lint‑Regeln und eine Migrations‑Runway. Sie behalten React dort, wo es hingehört; Sie hören auf, alles andere zu hydrieren.

FAQ für skeptische CTOs

„Wir haben in ein auf React gebautes Designsystem investiert. Werfen wir das jetzt weg?“

Nein. Behandeln Sie es als Island‑Library. Exportieren Sie Headless‑Primitives dort als Web Components, wo es Sinn ergibt. Die meisten visuellen Tokens, CSS und Accessibility‑Arbeit übertragen sich sauber.

„Was ist mit komplexem Client‑Caching und optimistischen Updates?“

Setzen Sie Konsistenz zuerst: Server‑autorisierte Mutationen, umhüllt von Transaktionen. Für wahrgenommene Geschwindigkeit streamen Sie Partials, nutzen Sie HTTP‑Caching aggressiv und wenden Sie optimistische UI auf die wenigen Interaktionen an, die es rechtfertigen. Sie brauchen keinen globalen Client‑Cache für eine Einstellungsseite.

„Verlieren wir knackige Transitions?“

Nutzen Sie Client‑seitiges Prefetch beim Hover, htmx‑boosted Links und partielle Swaps. Der Unterschied gegenüber SPA ist vernachlässigbar, wenn Sie ein Mittelklasse‑Telefon nicht zuerst 300 KB JS parsen lassen.

„Tauschen wir hier nicht nur eine Komplexität gegen eine andere?“

Doch — nur liegt die neue Komplexität näher an Ihren Daten und Invarianten, wo Sie bereits Tests, Transaktionen und Observability haben. Das ist der bessere Ort, um Ihr begrenztes Komplexitätsbudget auszugeben.

Eine einfache Regel, die Sie vor Ihrem CEO vertreten können

Wenn sich ein Screen als „Daten laden, Formular/Tabelle rendern, absenden und Ergebnis anzeigen“ beschreiben lässt, ist er so lange schuldig, bis das Gegenteil bewiesen ist, eine SPA‑Runtime zu benötigen. Nutzen Sie React dort, wo Kollaboration, Offline oder schwere Client‑Berechnung es eindeutig billiger machen. Überall sonst: Beenden Sie die Hydration‑Steuer.

Wichtigste Erkenntnisse

• Standardisieren Sie auf MPA + Progressive Enhancement; fügen Sie React als Island dort hinzu, wo es sich bezahlt macht.
• Bewerten Sie jede Oberfläche nach Interaktivitätsdichte, Kollaboration, Offline‑Bedarf, Navigationsmodell und SEO/regulatorischem Druck.
• Erwarten Sie 15–30% LCP/INP‑Gewinne und 20–40% weniger UI‑Incidents, wenn Sie CRUD‑Oberflächen de‑hydrieren.
• Migrieren Sie, indem Sie die SPA „würgen“: Starten Sie mit Auth, Marketing und Einstellungen; schneiden Sie dann eine servergerenderte Shell heraus; behalten Sie komplexe Widgets als Islands.
• Setzen Sie pro Route JS‑Budgets und verlangen Sie ADRs für jede neue SPA‑Oberfläche.
• Security und Compliance verbessern sich bei deterministischem Server‑Rendering mit weniger PII auf dem Client.
• Nutzen Sie ein erfahrenes Nearshore‑Pod, um Patterns zu säen, mit Ihrem Team zu pairen und in 8–12 Wochen mit Guardrails zu übergeben.