- Manche Entwickler glauben, dass SPA-Frameworks (React, AngularJS usw.) für die Entwicklung hochwertiger Anwendungen unverzichtbar sind
- Doch schon vor SPA haben MPA-basierte Anwendungen eine hervorragende User Experience geboten
- Ich habe versucht, mit HTMX eine datengetriebene, MPA-basierte Beobachtungsplattform zu entwickeln, und mit den richtigen Optimierungen können auch servergerenderte MPAs hervorragende Performance und User Experience liefern
Irrtümer und Tatsachen rund um MPA
Irrtum 1: MPAs sind beim Seitenwechsel langsam
- Problem: Standardmäßig lädt der Browser bei jedem Seitenwechsel JavaScript und CSS erneut herunter
- Lösung:
- Bibliotheken wie PJAX, Turbolinks oder HTMX Boost verwenden, um nur den HTML-
body auszutauschen
- Mit Service Workern lassen sich Seiten-Caching und Request-Verarbeitung verbessern
- Beispiel: Mit Service Worker verkürzt sich die DOMContentLoaded-Zeit von 2,9 Sekunden auf 500 ms
So wird ein Service Worker implementiert
- Datei
sw.js erstellen: Skript für Caching und Verwaltung von Netzwerkanfragen schreiben
- Liste der zu cachenden Dateien definieren: wichtige Assets wie HTML, CSS, JS festlegen
- Caching-Strategie festlegen: statische Assets dauerhaft cachen oder regelmäßig aktualisieren
Irrtum 2: MPAs können nicht offline laufen und keine Requests zur späteren Wiederherstellung der Netzwerkverbindung speichern
- Mit Service Workern kann die App auch im Offline-Zustand funktionieren
- Einsatz von Workbox:
- Bei Netzwerkfehlern Requests cachen und innerhalb von bis zu 24 Stunden erneut versuchen
- Offline-Handler einrichten, um bei Requests Ersatzinhalte bereitzustellen
Irrtum 3: MPAs verursachen beim Seitenwechsel ein Bildschirmflackern
- Lösung:
- Mit Service Workern und der Preload-API das Rendern verzögern, bis die Assets bereit sind
- Seit 2019 verarbeiten Browser Wechsel innerhalb derselben Domain ohne Flackern
Irrtum 4: In MPAs lassen sich keine aufwendigen Seitenübergangseffekte umsetzen
- SPAs sind für Seitenübergangsanimationen bekannt, aber Browser beginnen ebenfalls, dies zu unterstützen
- Mit Chrome 126 lassen sich Cross-Document-Transition-Animationen allein mit CSS umsetzen
- Demo-Link
Irrtum 5: In HTMX oder MPA wird jede Benutzeraktion auf dem Server verarbeitet
- HTMX ist so konzipiert, dass nur ein Teil der Aufgaben auf dem Server verarbeitet wird
- Falls nötig, lassen sich mit WebComponents oder JavaScript-Frameworks clientseitige interaktive Funktionen ergänzen
- Der SPA-Ansatz kann auch nur auf bestimmte Komponenten angewendet werden
Irrtum 6: DOM-Manipulation ist langsam. Deshalb braucht man React/Virtual DOM
- Der Virtual DOM zeigt nur bei extrem komplexen Anwendungen einen Performance-Unterschied
- In den meisten gewöhnlichen Anwendungen ist die direkte DOM-Manipulation schnell genug
- Weiterführend: "Virtual DOM is pure Overhead"
Irrtum 7: Selbst für kleine interaktive Funktionen ist JavaScript nötig
- Mit modernen Browser-Technologien lassen sich viele Funktionen auch ohne JavaScript umsetzen
- Toggle-Funktionen können mit HTML-Checkboxen und CSS gebaut werden
- In Kombination mit HTMX lassen sich Daten beim Klick asynchron laden
Letzter Irrtum: Ohne SPA verkommt clientseitiger Code zu Spaghetti-Code
- Auch in Zeiten von Spaghetti-Code wurde viel produktive Software entwickelt
- In der frühen MVP-Phase kann eine einfache Struktur sogar vorteilhafter sein
Fazit
- Im Jahr 2024 haben Browser vieles aus der SPA-Revolution übernommen und sich stark weiterentwickelt
- Schon mit den grundlegenden Browser-Werkzeugen (HTML, CSS, JavaScript) lassen sich interaktive, offlinefähige Anwendungen bauen
- Es lohnt sich, dem Potenzial des Browsers zu vertrauen und es noch einmal aktiv zu nutzen
8 Kommentare
Wenn man mal mit so mittelmäßigen Entwicklern entwickelt hat, merkt man sofort, wie wirklichkeitsfremd diese Vorstellung ist. Die Person, die das geschrieben hat, scheint entweder von Genies umgeben zu sein oder allein zu arbeiten ... (das sieht man schon daran, dass hier ausgerechnet veraltetes AngularJS erwähnt wird). Und Entwicklung wird nun mal nicht nur von Genies gemacht.
Manche würden das vielleicht als „unter sich bleiben“ abtun, aber Veränderungen wurden schon immer von ganz normalen Menschen herbeigeführt.
Wenn ich so etwas lese, denke ich zuerst, dass sich htmx auf keinen Fall durchsetzen darf.
Das ist in letzter Zeit immer wieder ein Thema,
Rich Harris hat vor ein paar Jahren ein Video veröffentlicht, in dem er seine Meinung zu diesem Thema darlegt.
https://www.youtube.com/watch?v=860d8usGC0o&t=635s
Wenn ich mich richtig erinnere, lässt sich das ungefähr so zusammenfassen: Bei Ansätzen, die auf Updates auf Basis von partiellem HTML setzen, kann es zu Inkonsistenzen zwischen Oberfläche und Daten kommen.
Glaubst du immer noch an Browser-Spezifikationen ...?
Wenn man es so sagen will, denke ich, dass SPA eine Methode zur App-Entwicklung ist, die etwas weniger von dem Verhalten des Browsers abhängt.
Es stimmt, dass Browser den großartigen Möglichkeiten von SPAs ziemlich weit gefolgt sind und dass das besser zu der ursprünglich für HTTP vorgesehenen Kommunikationsweise zu passen scheint. Aber liegt das nicht vielleicht daran, dass Chrome in der Browser-Welt faktisch eine monopolartige Stellung hat und dadurch Spielraum entstanden ist ...? Ich weiß nicht, ob so etwas wirklich lange anhalten wird. Ob nun der Spielraum oder der Marktanteil ...
Wenn es wie bei Phoenix LiveView ein WebSocket-basierter Ansatz ist, bei dem das DOM auf dem Server manipuliert wird, dann ist das ein anderes Paradigma.
Als ich htmx ausprobiert habe, fand ich es nicht besonders angenehm, dass der Server fragmentiertes HTML ausliefern muss.
Gerade beim CSS fühlt es sich, wenn Klassen festgelegt und mit ausgeliefert werden, so an, als würde man faktisch gemeinsames CSS erzwingen, weil der Server gar nicht wissen kann, welches CSS im Frontend gerade verwendet wird.
Ich habe vor einigen Jahren einmal versucht, mit Phoenix LiveView eine etwas komplexere UI zu bauen. Dabei war es viel zu umständlich, einfache Interaktionen umzusetzen, und weil eine einzelne LiveView von einem einzelnen Elixir-Prozess verarbeitet wird, sind Interaktionen mit benachbarten Komponenten sehr schwierig. Am Ende habe ich aufgegeben und bin wieder zu React zurückgekehrt.
LiveView fühlt sich für mich irgendwie nach der Zukunft an …
Da LiveView zudem stark vom Netzwerk abhängt, ist es in Fällen mit hohen Latenzen wegen eines entfernten Servers oder in Regionen wie der Dritten Welt mit schlechter Internet-Infrastruktur besonders anfällig.
Hacker-News-Kommentare
Es gibt die Frage, warum der Artikel nicht darauf eingeht, wie man statische CSS- und JS-Assets mithilfe des Browser-Caches verwalten kann. Als in der Vergangenheit eine Shopping-Seite als MPA gebaut wurde, waren Seitenwechsel fast nicht wahrnehmbar
Manche vertreten die Ansicht, dass Webentwicklung in der Ära von PHP und jQuery am produktivsten war. Es gibt auch die Meinung, dass frühere Paradigmen womöglich produktiver waren als moderne Technologien wie React. Selbst große Seiten wie Amazon oder Steam werden weiterhin so gebaut, dass HTML auf dem Server gerendert und anschließend JS hinzugefügt wird
Es wird um eine Erklärung gebeten, inwiefern Service-Worker-Strategien im Vergleich zu bestehenden HTTP-Cache-Headern besser sind. Zwar lassen sich Netzwerk-Roundtrips reduzieren, aber es wirkt auch so, als würde man für kleine Optimierungen das Ganze neu erfinden
Wegen des ausgelassenen Teils der Bedeutung im Titel „You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths“ wirkt der Titel etwas klickheischend
Das Gefährlichste beim Programmieren sind die Langeweile der Entwickler und die Unkenntnis der Vergangenheit
Es gibt die Meinung, dass nicht verständlich ist, warum in der Ära von Node.js-Webservern diese Dichotomie zwischen Server-seite und Client-Seite (SPA) existiert. Es wird gefragt, ob man nicht den Großteil der Arbeit auf dem Server initialisieren, zum Client serialisieren und dann als SPA laufen lassen könnte
SPA und MPA werden oft wie gegensätzliche Lager betrachtet, aber man kann auch zwischen einer natürlichen Nutzung des Web-Stacks und einem „Hack“-Ansatz unterscheiden. SPA ist derzeit ein Hack-Ansatz, früher gab es CGI, Java-Applets und Flash. Solche Hack-Ansätze erweitern die Grenzen der natürlichen Methode
Noch vor der Entscheidung für einen Technologie-Stack verstehen Entwickler oft falsch, was sie eigentlich bauen. Wenn kein hohes Maß an Interaktivität nötig ist, reicht in den meisten Fällen ein serverseitiges Framework aus
Es gibt eine Erwiderung auf den Mythos, dass man ohne Single-Page-App keine interaktive Webanwendung bauen könne. SPA bietet mehr Kontrolle und verringert die Wahrscheinlichkeit, Teile des Codes neu überarbeiten zu müssen
Die HN-Überschrift ist aggressiver als die eigentliche Überschrift. Es handelt sich um einen Essay von Tony Alaribe, vorgestellt auf der BigSkyDevCon, der Techniken dafür behandelt, wie sich nicht auf SPA basierende Webanwendungen schnell und flüssig machen lassen. Neue Techniken werden vorgestellt, und der Vortrag galt als der beste der Konferenz