Single Page App ist nicht immer die Lösung
SPA wird reflexartig gewählt. Für viele Use-Cases bringt Server-Rendered mit Livewire oder HTMX bessere Performance, weniger Komplexität und bessere SEO. Hier ist die Entscheidungsmatrix.
Frontend ehrlich gerechnet
Warum SPA der falsche Default ist
Vue, React, Angular werden gewählt, bevor irgendjemand gefragt hat, ob die Anwendung überhaupt eine Client-Routing-Logik braucht. Das ist Werkzeug-Reflex, keine Architektur.
Time to Interactive ist die ehrliche Metrik
Eine durchschnittliche Vue-3-SPA mit Vite, Pinia und Vue-Router liegt nach Tree-Shaking bei 150 bis 300 KB JavaScript. Das muss der Browser laden, parsen, ausführen, hydratisieren - und erst dann ist die Seite klickbar. Auf einem Mittelklasse-Android-Gerät über LTE reden wir von 2 bis 4 Sekunden TTI. Server-Rendered HTML mit Livewire ist klickbar, sobald das HTML da ist: 200 bis 400 ms. Der Unterschied ist nicht Geschmack, sondern Faktor zehn.
SEO ist kein Nachgedanke
Google rendert JavaScript inzwischen - aber langsamer, mit Verzögerung und nicht zuverlässig für alle Crawler. Bing, LinkedIn-Preview, WhatsApp-Preview, Slack-Preview, ChatGPT-Browsing: alle erwarten serverseitiges HTML. Wer SEO ernst meint, liefert HTML beim ersten Byte. Punkt. SSR mit Inertia oder Nuxt löst das, fügt aber gleich wieder Komplexität hinzu, die man oft gar nicht braucht.
Die Alternativen
Livewire und HTMX als pragmatische Wahl
Server-Rendered HTML mit selektivem Re-Rendering deckt 70 bis 80 Prozent dessen ab, wofür heute SPAs gewählt werden - bei einem Bruchteil der Komplexität.
Livewire 4: PHP rendert, Browser updated
Livewire schreibt Ihnen in PHP - eine Komponenten-Klasse, ein Blade-Template. Beim Klick geht ein Request raus, das Backend rendert das diff-HTML, Livewire patcht den DOM. Keine getrennte API, kein State-Management auf zwei Ebenen, keine Type-Sync zwischen Backend und Frontend. Wir haben Dashboards mit Filtern, Pagination, Sortierung und Drag-Drop in unter 2.000 Zeilen PHP gebaut, die in Vue mindestens 5.000 Zeilen TypeScript gewesen wären.
HTMX: HTML als API
HTMX dreht das Paradigma um: Ein einziges Attribut wie hx-get="/items" lädt HTML-Fragmente und ersetzt Teile der Seite. Kein Build-Step, kein JavaScript-Bundle, kein Hydration-Drama. Für CRUD-Oberflächen, Admin-Panels, Backoffice-Tools ist HTMX oft die ehrlichste Wahl - und kombiniert sich glänzend mit Laravel-Blade oder Statamic-Antlers.
Frontend-Entscheidung anstehend?
Wir vergleichen SPA, Livewire und HTMX für Ihren konkreten Use-Case - mit Zahlen, nicht mit Folien.
Wann SPA wirklich richtig ist
Die seriösen SPA-Auslöser
Es gibt klare Fälle, in denen Vue oder React objektiv überlegen sind. Hier sind sie.
Hochfrequente Echtzeit-UIs
Trading-Dashboards, Live-Maps, kollaborative Editoren à la Figma, Realtime-Spielfelder: hier zählt jeder Frame und jeder Request-Roundtrip ist zu langsam. WebSocket-getriebene SPAs mit Client-State sind dann der richtige Weg. Vue 3 mit Pinia und einem schlanken WebSocket-Layer ist unser bevorzugtes Setup für solche Anforderungen.
Komplexer Client-State quer durch viele Views
Wenn Ihr Frontend einen Warenkorb, einen Konfigurator und einen Wizard gleichzeitig managt, mit Undo-Stack, lokalem Cache und Optimistic Updates, gewinnt eine SPA. Server-Rendered HTML kann das auch - wird aber unübersichtlich. Hier ist eine SPA die ehrlichere Antwort.
Offline-fähige Progressive Web Apps
Sobald Ihr Frontend offline funktionieren muss - Außendienst-Apps, Lager-Scanner, mobile Inspektions-Tools -, braucht es Service-Worker, IndexedDB und einen Client-Renderer. Das ist klassisches SPA-Terrain. Vue mit Workbox und einer sauberen Sync-Strategie liefert hier verlässlich.
Die Mittelweg-Lösung
Inertia: SPA-Gefühl, Backend-Routing
Es gibt einen sauberen Mittelweg, falls Sie Vue oder React mögen, aber kein eigenes API-Layer pflegen wollen.
Eine Codebasis, ein Routing
Inertia.js verbindet Laravel-Routes mit Vue- oder React-Komponenten. Das Backend rendert Props, Inertia übergibt sie an die Komponente, beim ersten Request kommt SSR-HTML, danach läuft es als SPA weiter. Kein zweites API-Projekt, keine OpenAPI-Spec, kein Frontend-Backend-Sync. Diese Site läuft auf genau diesem Stack mit Inertia v2.
Inertia v2 mit Deferred und Polling
Mit Inertia v2 ziehen wir teure Daten als Deferred Props nach, pollen Hintergrund-Updates ohne SPA-Komplexität und liefern SEO-relevante Inhalte via SSR ab Byte eins. Für mittlere bis komplexe Anwendungen mit Login-Bereich ist das unsere Standardwahl: SPA-UX, ohne SPA-Steuer.
Wann selbst Inertia zu viel ist
Wenn Ihr Projekt eine Marketing-Site, ein Blog oder ein klassisches CMS-Frontend ist, ist auch Inertia überdimensioniert. Statamic mit Antlers oder Blade, Tailwind v4 und Alpine.js liefert hier alles, was nötig ist - mit unter 30 KB JavaScript auf der Seite. Wir haben diese Site genau so gebaut.
Artikel teilen
Lassen Sie uns reden
Bevor Sie sich auf ein Frontend-Framework festlegen, lohnt ein ehrlicher Stack-Check.
Wir prüfen Ihren Use-Case anhand harter Kriterien - Time to Interactive, SEO-Anforderungen, Team-Größe, Wartungsaufwand - und empfehlen die Lösung, die zu Ihrem Kontext passt. Manchmal ist das Vue. Manchmal Livewire. Oft Inertia. Selten alles drei gleichzeitig.