Das Pendel ist zurückgeschwungen
Single-Page-Apps haben das letzte Jahrzehnt dominiert. 2026 gehen die klügsten Teams leise den umgekehrten Weg.
Niemand verabschiedet sich von React. Niemand erklärt JavaScript den Krieg. Sie liefern einfach weniger davon aus.
HTMX hat 2024 rund 16.800 GitHub-Sterne dazugewonnen. Hotwire ist der Standard für jede neue Rails-8-Anwendung. React Server Components und der Next.js App Router sind das Eingeständnis des React-Teams, dass HTML vom Server zu streamen eine gute Idee ist.
Die Diskussion 2026 lautet nicht mehr “SPA gegen server-gerendert”. Sie lautet: “Wie viel Client-JavaScript brauchen Sie wirklich?”
Für die meisten B2B-Anwendungen ist die Antwort: deutlich weniger, als Sie bisher ausgeliefert haben.
Zwei Werkzeuge, dieselbe Idee
HTMX ist eine etwa 16 KB große JavaScript-Bibliothek (minified und gzipped). Sie hängen ein Attribut an einen Button, und der Button schickt einen HTTP-Request. Der Server liefert HTML zurück, und HTMX tauscht es in der Seite aus.
Das ist der gesamte Pitch. Kein Build-Schritt. Kein npm-Abhängigkeitsbaum. Kein Virtual DOM.
Hotwire ist dieselbe Idee, gepackt für Rails (und über Ports inzwischen auch für Phoenix, Django und Laravel). Turbo übernimmt Seitennavigation und Streaming-Teilupdates. Stimulus fügt kleine JavaScript-Prisen hinzu, wenn Sie sie wirklich brauchen.
Beide erlauben Ihnen, eine server-gerenderte Anwendung zu schreiben, die sich wie eine SPA anfühlt. Der Unterschied: Sie liefern Kilobyte aus, nicht Megabyte.
Ein typisches React + Next.js + State-Library-Bundle liefert rund 250-500 KB JavaScript aus, bevor Ihr eigener Code überhaupt startet. Hotwire liefert etwa 30 KB. HTMX rund 16 KB.
Diese Lücke wiegt heute schwerer als früher. INP (Interaction to Next Paint) hat im März 2024 FID als Core-Web-Ranking-Signal abgelöst, und Google bewertet Seiten danach. Jedes Skript, das den Main-Thread blockiert, kostet Sie Ranking und Conversions.
Was sich 2026 wirklich verändert hat
HTMX 2.0 (Juni 2024) hat IE11-Support gestrichen, alte Attribut-Aliase entfernt und WebSocket sowie SSE in Extensions ausgelagert. Kleinerer Kern. Klareres Modell.
Die 2.0.x-Punktreleases seitdem (aktuell: 2.0.10, April 2026) haben die Swap-Semantik geschärft und eine öffentliche htmx.swap()-API für saubere Teilersetzungen ergänzt. HTMX 4.0 ist in Beta mit einem Sommer-2026-Ziel und ersetzt XHR durch fetch() unter der Haube.
Turbo 8 (Anfang 2024) lieferte Page-Level-Morphing aus. Statt komplette DOM-Bäume auszutauschen, vergleicht und patcht Turbo direkt im Baum, sodass Formulare ihren Fokus behalten und Scroll-Positionen bleiben, wo sie waren. Nutzer merken den Wechsel nicht.
In Kombination mit Turbo Streams über WebSockets bekommen Sie optimistische Updates und Echtzeit-Kollaborationsmuster, ohne eine einzige Zeile Client-State-Management zu schreiben.
Phoenix LiveView, Laravel Livewire, Django Unicorn. Dasselbe Architekturmuster, andere Ökosysteme. Das Muster hat sich durchgesetzt.
Wo server-gerendert gewinnt
CRUD-Apps, also die meisten Apps
B2B-SaaS besteht aus Formularen, Tabellen, Dashboards und Berichten. Ein Nutzer klickt eine Zeile an, sieht die Detailseite, ändert ein Feld und speichert.
Sie brauchen dafür keine 400 KB Client-State. Sie brauchen schnelle Seitenaufbauten und flotte Übergänge.
Hotwire und HTMX liefern beides mit einem Entwickler statt drei. Wir haben die Framework-Seite davon in Warum wir 2026 immer noch Rails für B2B-SaaS wählen ausführlich beschrieben. Dieselbe Logik gilt für Django, Phoenix oder Laravel.
Interne Tools und Admin-Bereiche
Basecamp. HEYs Webmail. GitHubs eingeloggte Navigation läuft über Turbo Drive auf einem Rails-Backend. Die neuen ONCE-Produkte von 37signals setzen denselben Stack ein. Alle bedienen täglich große professionelle Nutzergruppen mit einem Bruchteil des JavaScripts, das eine vergleichbare React-App bräuchte.
Internen Nutzern ist es egal, ob das Dashboard in 600 ms oder 200 ms lädt. Wichtig ist, dass es funktioniert, konsistent aussieht und ohne separates Frontend-Team gepflegt werden kann.
Ein konkretes Beispiel. Ein Fertigungskunde betrieb sein Admin auf einem Next.js + GraphQL-Stack, den die Vorgängeragentur gebaut hatte. Drei Entwickler, vierzehn Monate Arbeit, immer noch fehlerhaft. Das “Admin” bestand aus drei Bildschirmen: Kunden, Bestellungen, Produkte.
Wir haben es in Rails mit Hotwire neu gebaut. Sechs Wochen, ein Entwickler. Dieselben Bildschirme, schneller, weniger Bugs. Den React-Stack haben sie für ihren öffentlichen Storefront behalten. Anderes Problem, anderes Werkzeug.
Compliance-lastige Produkte
Wenn Sie Software für Healthcare, Finanzdienstleistung oder Verwaltung ausliefern, ist jede Zeile Client-JavaScript ein potenzielles Audit-Risiko. Jede Drittanbieter-npm-Abhängigkeit ist ein Lieferketten-Risiko.
Eine Rails-8-Anwendung mit importmap-rails bringt null npm-Pakete mit: Turbo und Stimulus kommen als ESM-Module direkt aus dem Asset-Pipeline. Ein frisches create-next-app löst über tausend transitive Abhängigkeiten auf, bevor Sie eine einzige Zeile Code geschrieben haben. Dieser Unterschied schlägt in Pen-Tests und SBOM-Berichten durch.
Public-Sector-Teams greifen genau aus diesem Grund vermehrt zu HTMX. Keine Build-Pipeline. Kein Webpack-Lockfile zum Auditieren. Eine Anwendung, die Sie an einem Nachmittag von oben bis unten lesen können.
Überall, wo Sie kein Frontend-Team haben
Die meisten Unternehmen haben kein eigenes Frontend-Team. Sie haben eine kleine Gruppe von Full-Stack-Entwicklern, die nicht über Webpack-Konfigurationen nachdenken wollen.
Für sie kollabieren Hotwire und HTMX den Stack. Eine Sprache, ein Framework, ein Deployment. Kein Koordinationsaufwand und kein “Das API-Team muss erst dieses Feld hinzufügen, bevor wir den Screen bauen können”, sondern ein Entwickler, der Features end-to-end ausliefert.
Wo SPAs immer noch gewinnen
Ehrliche Einschätzung: SPAs gewinnen manchmal weiterhin. Wir haben React, Vue und Svelte ausgeliefert, wenn es die richtige Wahl war. Hier sind die Fälle.
Echtzeit-Kollaboration. Figma, Miro, Notion, Linear. Solche Anwendungen müssen tausende Objekte im Client-Speicher verwalten, State zwischen Nutzern in Millisekunden synchronisieren und auch bei intensiven Bearbeitungen reaktionsschnell bleiben. Server-gerenderte Modelle brechen hier zusammen.
Canvas- und Kreativ-Werkzeuge. Zeichen-Apps, Video-Editoren, Level-Editoren, alles mit Drag-and-Drop auf einer 2D-Fläche. Diese Anwendungen sind von Natur aus client-lastig. Kämpfen Sie nicht dagegen an.
Offline-First. PWAs, die ohne Netzwerkverbindung funktionieren müssen, müssen State im Browser halten. Server-gerenderte Ansätze setzen einen erreichbaren Server voraus.
Single-Purpose-Anwendungen mit tiefer Interaktion. Eine Tabellenkalkulation. Ein Code-Editor. Ein Projektplaner mit Gantt-Diagramm. Die Interaktivität ist das Produkt.
Der ehrliche Test: Ist die Interaktivität essenziell für das, was Nutzer tun, oder Politur auf einem CRUD-Kern? Wenn Politur, dann liefern Hotwire oder HTMX 95 % der Erfahrung für 5 % der Komplexität.
React ist leise zur selben Schlussfolgerung gekommen
Das Spannendste am React-Ökosystem 2024-2025: React selbst ist serverseitig geworden.
React Server Components laufen auf dem Server, rendern HTML und streamen es inkrementell zum Browser. Der Next.js App Router setzt standardmäßig auf Server Components. Client Components sind jetzt Opt-in.
Lesen Sie das nochmal. Das Framework, das die SPA-Ära definiert hat, behandelt Client Components als Opt-in.
Warum? Weil das React-Team bemerkt hat, was Rails-Entwickler seit zwei Jahrzehnten wissen: Die meisten Teile einer Anwendung müssen nicht interaktiv sein. Auf dem Server rendern, das HTML ausliefern, nur die Stellen hydratisieren, die sich tatsächlich bewegen.
Dieselbe Architektur wie Hotwire. Dieselbe wie HTMX. Dieselbe wie Phoenix LiveView. Andere Etiketten, dasselbe Muster.
Inertia.js: Der pragmatische Mittelweg
Für Kunden, die wirklich ein reichhaltigeres Frontend brauchen (denken Sie an Dashboards mit komplexen Filtern, Drag-and-Drop-Kanban, eingebettete Datenvisualisierung), greifen wir zu Inertia.js.
Inertia erlaubt Ihnen, Rails- oder Laravel-Controller zu schreiben, die Daten zurückgeben. Die Daten werden über eine React- oder Vue-Komponente gerendert. Kein separater API-Server. Kein CORS. Kein dupliziertes Routing. Kein GraphQL-Schema zur Pflege.
Inertia 2.0 (März 2025) hat den verbleibenden Abstand zu einer handgebauten SPA weitgehend geschlossen. Deferred Props, Prefetching beim Hover, Polling und eine WhenVisible-Komponente. Sie bekommen Reacts Komponentenmodell mit der Produktivität eines server-gerenderten Frameworks, für die kleine Menge an Anwendungen, die wirklich beides brauchen.
Was wir 2026 für Kunden ausliefern
Standard: Rails 8 + Hotwire + PostgreSQL auf einem einzelnen Hetzner-Server. Gesamte Infrastrukturkosten: 40-80 EUR pro Monat. Zeit bis zum funktionierenden MVP: 6-10 Wochen.
Wenn die Anwendung es rechtfertigt: Rails oder Laravel + Inertia + React. Kostet zwei bis drei Wochen zusätzliches Frontend-Setup. Rechnet sich, sobald Sie einen komplexen Screen brauchen.
Wenn HTMX die bessere Wahl ist: Python- oder Go-Backends, deren Teams keine JavaScript-Build-Pipeline wollen. Verwaltungs- und Behördenarbeit. Audit-lastige Umgebungen. Interne Tools, die dasselbe Team über Jahre pflegt.
Wenn eine reine SPA richtig ist: Echtzeit-Kollaboration, Canvas-Werkzeuge, Offline-First-Produkte. Dann liefern wir React oder SvelteKit aus, passend gehostet.
Die Entscheidung lautet nicht “Was ist das Beste?”. Sie lautet “Was passt zu dieser Anwendung?”. 2026 ist die Antwort meistens “Weniger JavaScript, als Sie denken”.
Wenn Sie tiefer in unsere Stack-Entscheidungen einsteigen möchten, zeigt unsere Sicht auf die wahren Kosten technischer Schulden, warum die Wahl der Architektur ein Business-Thema ist und keine Geschmacksfrage.
Sie bauen ein B2B-Produkt und fragen sich, ob Sie wirklich eine vollständige SPA brauchen? Lassen Sie uns darüber sprechen. Wir prüfen Ihre Anforderungen ehrlich und sagen Ihnen, wann server-gerendert mehr Sinn ergibt als der nächste React-Build.
