Laravel + Livewire oder React-SPA: danach entscheiden, wo der State lebt
Livewire hält den Anwendungs-State auf dem Server: Interaktionen sind Round-Trips, Blade rendert Fragmente neu, Eloquent bleibt die einzige Quelle der Wahrheit. React hält State im Browser und spricht mit einer API. Business-Apps aus Formularen und Tabellen wollen das erste; dichte, sofortige, offline-fähige Interfaces wollen das zweite.
Ich habe beides ausgeliefert, und die Framework-Frage war der falsche Startpunkt. Die richtige Frage lautet: Wo lebt die Wahrheit des aktuellen Bildschirms?
Wann schlägt Livewire eine React-SPA?#
Wenn das Produkt eine Formular-und-Tabellen-Anwendung ist, die Laravel bereits modelliert: Admin-Panels, Kundenportale, interne Tools. Konkret:
- Validierung lebt einmalig in Form Requests. Es gibt keine zweite JavaScript-Implementierung derselben Regeln, die auseinanderläuft.
- Autorisierung nutzt Laravel Policies. Es gibt keine API-Schicht, deren Schutz man vergessen kann, weil es keine API-Schicht gibt.
- Seiten sind standardmäßig servergerendert: Suchmaschinen sehen Inhalte ohne SSR-Pipeline.
- Ein Deploy, ein Log-Stream, ein Error-Tracker.
Der Preis: Jede Interaktion kostet einen Netzwerk-Round-Trip. Das ist fein für „speichere dieses Formular“ und falsch für „zieh diesen Slider, während dreißig Zeilen neu sortieren“. Am Tag, an dem ein UI sofortiges Feedback auf dichten lokalen State braucht, beginnt Livewire zu kämpfen: wire:model.live-Debouncing, aufblitzende Loading-Platzhalter und eine Request-Rate, die mit jedem verdrahteten Input wächst.
Wann gewinnt die SPA?#
React (mit Next.js für alles URL-sichtbare) verdient seine Toolchain, wenn das Interface das Produkt ist: Editoren, Dashboards mit dichter lokaler Interaktivität, alles Offline-fähige, Screens, bei denen optimistische Updates wichtiger sind als Request-Zahlen. State lebt dort, wo die Interaktion passiert, das UI wartet nie aufs Netz, um sich responsiv anzufühlen.
Die Kosten sind das Spiegelbild: ein API-Vertrag zum Versionieren, eine zweite Authentifizierungsgrenze zu verteidigen, SEO bewusst zu bauen, und zwei Deploys statt einem. Diese Kosten sind es wert für das richtige Produkt und Verschwendung für das falsche.
Side by side#
| Dimension | Livewire 3 | React-SPA |
|---|---|---|
| State-Location | Server (Session, Datenbank) | Browser + API |
| Interaktions-Latenz | Ein Netzwerk-Round-Trip | Sofort, lokal |
| Backend | Eloquent, Blade, eine App | Separater API-Vertrag |
| SEO | Servergerendert | Braucht SSR (Next.js) |
| Team-Basis | PHP, Blade | TypeScript, Build-Tooling |
| Offline-Nutzung | Nein | Machbar |
| Ecosystem | Laravel-Pakete | npm, um Größenordnungen größer |
Was in der Praxis jeweils entschied#
Ein Operations-Portal mit rund vierzig Screens (Formulare, Tabellen, Freigaben, Exporte) läuft auf Livewire und wollte nie eine SPA sein: Jeder Screen mappt auf Server-State, das Ganze ist eine Laravel-App.
Die Röstwerk-Mini-App ist React, genau weil ein Warenkorb in einer Telegram-Webview sofortiges lokales Feedback auf Zwischensumme, Menge und Validierung braucht. Das serverseitig pro Tap zu rendern wäre spürbar und schlechter gewesen.
Diese Seite ist Next.js, weil ein Blog mit Befehlspalette, Theme-Wechsel und Lese-Fortschritt genau die Art Interface ist, für die React gebaut wurde. Was diese Wahl bis zu den Lighthouse-Zahlen gebracht hat, steht separat: der Performance-Durchlauf im Detail.
Livewire führt die Komponenten-Lifecycle bei jedem Update erneut aus. Ein Suchfeld, das pro Tastenanschlag feuert, ist ein Datenbank-Hammer: bewusst debouncen, teure Renders aus dem Hot Path halten und die Request-Rate in den DevTools beobachten, bevor die Nutzer sie einem über die Load Average beibringen.
Die Migration, für die niemand Budgetiertes einstellt#
Falsch gewählt ist reparabel. Der teure Teil ist nicht das Portieren von Komponenten, sondern das Neuzeichnen der State-Grenze. Serverseitigen State in einen Client-Store zu verschieben heißt, die API, die Optimistic-Update-Regeln und die Invalidierungslogik zu erfinden, die man zuvor gratis bekam. Wer diese Migration erwartet, plant die Notluke wie jede andere Migration ohne Big Bang: schrittweise, pro Screen, mit dem alten Weg intakt, bis sich der neue bewiesen hat.
Es gibt keinen Stack, der auf beiden Achsen gewinnt. Einmal schriftlich festlegen, wo der State jedes geplanten Screens lebt. Die Framework-Wahl fällt aus diesem Satz heraus.