Es ist Zeit, dass modernes CSS die SPA ersetzt

• Mit dem Aufkommen moderner CSS-Funktionen wie der View Transitions API ist eine SPA-Architektur für flüssige Seitenübergänge heute nicht mehr nötig
• Die meisten SPA-Websites liefern in der Praxis weder die erwartete Performance noch ein wirklich flüssiges Erlebnis; stattdessen verschlechtert schwergewichtiges JavaScript oft die User Experience
• Mit nativen Seitenübergängen und Speculation Rules in Chromium-basierten Browsern lassen sich schnelle und natürliche Navigationen auch ohne JavaScript umsetzen
• Die komplexe Struktur von SPAs behindert Browser-Optimierungen; für reale Websites ist eine auf HTML und CSS basierende MPA-Struktur oft schneller und leichter zu pflegen
• Künftig sollte man die unnötige Einführung von SPAs vermeiden und stattdessen effiziente, wartungsfreundliche Websites mit modernem CSS und nativen Funktionen entwickeln

---

Einleitung: Das Ende der SPA und das Aufkommen von modernem CSS

• Mit der Einführung moderner CSS-Funktionen wie der View Transitions API ist die Situation eingetreten, dass die wichtigsten bisherigen Vorteile klassischer SPAs (Single Page Applications) nicht mehr benötigt werden
• Viele Entwicklerteams greifen weiterhin zu SPA-Frameworks wie React oder Vue, doch der Kern dieser Entscheidung ist nicht Performance, sondern ein Missverständnis über Interaktion und flüssige Navigationserlebnisse
• Die Annahme, eine SPA sei für nahtlose Navigation unverzichtbar, ist inzwischen bereits ein überholtes Denkmuster

Der Mythos der SPA und die Realität

• Eine SPA war einst der einzige Weg, besonders natürliche Seitenübergänge zu realisieren, doch das ist heute nicht mehr der Fall
• Viele SPAs haben unter anderem folgende Probleme:
  • Oft gibt es nur Fade-Effekte für Ladezustände, aber keine wirklich weichen Inhaltsübergänge
  • Probleme bei der Wiederherstellung der Scroll-Position und uneinheitliches Fokusverhalten
  • Verzögerungen bei der Navigation durch Rendering- und Hydration-Latenzen
  • Layout Shifts, aufpoppende Inhalte und Skeleton-Loading
  • Unnötige Komplexität und übermäßiger JavaScript-Einsatz bei geringem Nutzen für die Performance
• Bekannte SPA-Frameworks wie Next.js, Gatsby und Nuxt fügen große Mengen an JS-Code hinzu, um grundlegendes natives Browser-Verhalten nachzuahmen
• Das führt letztlich dazu, dass native Natürlichkeit geopfert wird, die Geschwindigkeit sinkt und auch SEO leidet

Die Weiterentwicklung der Webplattform und der Wandel der Rolle von CSS

• Moderne Chromium-basierte Browser wie Chrome und Edge unterstützen native, deklarative Seitenübergänge
• Mit der View Transitions API lassen sich auch ohne JavaScript flüssige Animationen zwischen Dokumenten oder ganzen Seiten umsetzen
• Zu den Kernfähigkeiten gehören:
  • Fade-Effekte zwischen Seiten (mit nur 3 bis 4 Zeilen CSS umsetzbar)
  • Shared-Element-Animationen wie der natürliche Übergang von einem Thumbnail zu einer Detailansicht
  • Das Beibehalten persistenter Elemente wie Header oder Navbar
  • Da echte URLs und echte Seitenwechsel genutzt werden, werden SEO, Link-Sharing sowie Back/Forward Cache bestmöglich unterstützt

Wie sich die Synergie von CSS und JS voll ausschöpfen lässt

• Falls nötig, kann mit JS auch innerhalb einer Seite manuell eine View Transition ausgelöst werden
• Beispiele: Theme-Wechsel, Tab-Umschaltung oder Dark-Mode-Umschaltung mit nur minimalem JavaScript

Speculation Rules und sofortige Navigation

• Speculation Rules ermöglichen es dem Browser, Seiten vorab vorzuladen oder vorzurendern und Nutzerverhalten wie Mouseover zu antizipieren, um sofortige Navigation zu liefern
• Die Konfiguration ist deklarativ über <script type="speculationrules"> möglich
• Voraussetzung: Wenn Seiten leichtgewichtig und optimiert sind, ist der Performance-Gewinn maximal; bei schweren Seiten droht dagegen Ressourcenverschwendung

Respekt für Browser-eigene Funktionen und bfcache

• bfcache (Back/Forward Cache) stellt beim Zurück- oder Vorwärtsnavigieren ganze Seiten als Snapshot sofort wieder her
• Voraussetzung dafür ist eine saubere Architektur auf Basis von reinem HTML und CSS; bei Strukturen, die wie SPAs das Routing abfangen, ist dies nicht möglich
• Daraus folgt: Moderne Browser entwickeln sich in eine Richtung, in der einfache und robuste Websites belohnt werden

Performance-Vergleich zwischen SPA und MPA

• Durchschnittliche SPA (auf Basis von Next.js):
  • JS-Bundle-Größe: 1–3 MB
  • TTI (Time to Interactive): 3,5–5 Sekunden
  • Routenwechsel: künstlich/simuliert
  • SEO: komplex, schwer zu pflegen
  • Scroll-/Anchor-Verhalten: instabil
• Moderne MPA (mit CSS-Übergängen und Speculation Rules):
  • JS-Bundle: 0 KB (nur optionale Erweiterungen)
  • TTI: etwa 1 Sekunde
  • Routenwechsel: echtes natives Verhalten
  • SEO: sehr einfach
  • Intelligentes Scrollen, Fokus, Verlauf: Browser-Standardverhalten mit vollständiger Unterstützung

Die Abgrenzung zwischen Website und App – und warum Eignung neu bewertet werden muss

• Die meisten Websites sind in Wirklichkeit keine „Apps“ und benötigen keinen geteilten Zustand, kein Client-seitiges Routing und keine komplexen Interaktionen
• Für Marketingseiten, Dokumentationsportale, E-Commerce und Blogs ist eine HTML-zentrierte, schnell ladende und einfache Struktur besser geeignet
• Wenn in jedem Projekt ein SPA-Stack eingeführt wird, kann das zu übermäßiger Komplexität und schlechterer Performance führen
  1. Die Forderung, „wie eine App auszusehen“
  2. Einführung eines Frameworks
  3. Client-seitiges Routing und steigende Komplexität
  4. Schlechtere Performance und zusätzlicher Optimierungsbedarf
  5. Und trotzdem langsamer als native Link-Wechsel plus CSS-Animationen

Fazit und Empfehlung

• SPAs waren in der Vergangenheit eher eine Notlösung für Plattformgrenzen, doch diese Beschränkungen bestehen heute nicht mehr
• Heute lassen sich die folgenden nativen Funktionen aktiv nutzen:
  • Echte Übergänge zwischen Seiten
  • Sofortiges Pre-Rendering über Speculation Rules
  • Eine Struktur, die gegenüber Funktionsverlust robust ist
  • Sauberes Markup, schnelles Laden und echte URLs
  • Eine Architektur, die maximale Unterstützung von der Plattform erhält
• Wer an einer SPA nur wegen der „Flüssigkeit“ festhält, bezahlt am Ende mit Komplexität, Performance und Wartbarkeit
• Mit Server-Rendering, echten Seiten, CSS-basierten Animationen, bewusstem Preloading und minimalem JS lassen sich zeitgemäße, schnelle und angenehme Websites bauen
• Mit dem Stand der Technik im Jahr 2025 sollte das Ziel ein schnelleres, einfacheres und für alle zugänglicheres Web-Erlebnis sein

[nemorize]

Ursprünglich hätte ich in Situationen, in denen man ein SPA allein wegen der „Flüssigkeit“ in Betracht zieht, lieber einfach auf diese Flüssigkeit verzichtet und es als MPA umgesetzt, daher kann ich mich damit nicht wirklich identifizieren ...

[longface0908]

Was dem Artikel fehlt

1. Der eigentliche Zweck von SPA wird zu stark verkürzt interpretiert
   Die View Transitions API ist wirklich großartig, aber allein dadurch werden SPAs nicht überflüssig.

2. Alle Websites werden nach denselben Maßstäben betrachtet
   Marketing-Website ≠ Dashboard ≠ Commerce-App ≠ Echtzeit-Kollaborationstool
   Alle haben unterschiedliche strukturelle Anforderungen.

3. In der Praxis koexistieren SPA + SSR + MPA
   Hybride Frameworks wie Next.js zeigen das sehr gut.
   Für statische Assets ist SSG sinnvoll, für Dashboards nach dem Login CSR/SPA, für Suchmaschinenkompatibilität SSR – es braucht also eine flexible Kombination.

Ich denke, SPA ist nicht nur ein Ergebnis der Verbesserung der User Experience, sondern eher ein Produkt struktureller Verbesserungen.
Für Seiten, auf denen SPA nicht nötig ist, kann MPA + modernes CSS eine gute Wahl sein. Aber in Bezug auf Architektur, State, Skalierbarkeit und Wartbarkeit bleibt SPA weiterhin essenziell. Ich denke, modernes CSS kann SPA zwar "ergänzen", aber nicht "ersetzen".

[spp00]

Von den von Ihnen angeführten Beispielen gibt es praktisch nur bei Echtzeit-Kollaborationstools etwas, das sich nicht durch SPA mit Dingen wie View Transitions ersetzen ließe — aber die große Mehrheit der Websites sind keine Echtzeit-Kollaborationstools. Marketingseiten, Dashboards und Commerce-Apps lassen sich alle auch ohne SPA-Frameworks umsetzen, wenn man die Bedingungen Server-Rendering, echte Seiten, CSS-basierte Animationen, bewusstes Preloading und den Einsatz eines Minimums an JS einhält. In der Rails-Welt gibt es dafür auch Hotwire, und dafür existieren mit Basecamp und Hey zudem Produktionsbeispiele. State Management? Solange es nicht um so etwas wie Echtzeit-Kollaborationstools geht, reichen serverseitige Methoden wie URL-Parameter oder Server-Sessions oder auch Local Storage völlig aus. Es gibt eindeutig Fälle, in denen allein wegen der Seitenübergänge SPA eingeführt wird (wie etwa die offizielle Website von AGF, wo Astro eigentlich völlig ausgereicht hätte, aber trotzdem React eingeführt wurde), und man kann nicht bestreiten, dass Seitenübergänge häufig als einer der zentralen Vorteile von SPA genannt werden.

[sonnet]

Es stimmt zwar, dass man bei aktuellen SPA-Frameworks und den darauf basierenden Frontend-Trends weiterhin vorsichtig gegenüber fehlender Standardisierung sein muss und dass sie leicht zu Overengineering und unnötigem Ressourcenverbrauch führen können, aber …

Auch das Konzept eines SPA wird hier zu eng betrachtet, doch noch mehr frage ich mich, ob man versteht, welchen Einfluss SPA-Frameworks auf die Entwicklung insgesamt haben.

Zu sagen, mit nur einer View-Transition-API und etwas CSS sei alles erledigt, heißt anders formuliert, dass alle davon unabhängigen Funktionen und auch die Paradigmen zu ihrer Umsetzung völlig bedeutungslos seien — das erscheint mir keine zu arrogante Sichtweise zu sein.

Das ist wiederum ein anderes Problem als das Overengineering, wenn man eine Website, die kaum mehr als eine Broschüre ersetzt, mit React baut.

Ich stimme zu, dass die meisten kleinen Projekte nicht unbedingt ein SPA-Framework brauchen. Aber bei Services, deren Anforderungen komplexe Interaktionen, eine kontinuierliche User Experience sowie die daraus folgende Wartung und laufende Verbesserung umfassen, sehe ich das trotz der Weiterentwicklung von CSS anders.

[sonnet]

Ehrlich gesagt wirkt das so, als würde man über Rust oder Haskell, die man nicht einmal angefasst hat, sagen: „Das braucht man nicht, heutzutage geht mit C++ sowieso alles.“

[ahwjdekf]

Hm, ich weiß nicht so recht. Dient der Einsatz von SPA-Frameworks nicht eher komplexen Interaktionen mit den Nutzern als weichen Übergängen?

[spp00]

Es gibt sicherlich Fälle, in denen ein SPA-Framework allein wegen einer einzigen flüssigen Interaktion eingeführt wird. Bei einem erheblichen Teil der Websites, auf denen SPAs eingesetzt werden, sind komplexe Interaktionen gar nicht nötig.

[howudoin]

Stimme weitgehend zu
Ein prägnantes Beispiel ist, dass React selbst so etwas wie das Spring des Frontends ist
es ist schwergewichtig und komplex; es wirkt, als würde die Arbeit dadurch bequemer, aber in Wirklichkeit richtet man für leichte Aufgaben erst einen noch komplexeren Prozess ein und schafft dann einen seltsam bequemen Komfort, der genau diesen unnötig verkomplizierten Prozess handhabbarer macht

[spp00]

Ich stimme zu. Sofern es sich nicht um eine komplexe Web-App wie Google Docs handelt, reicht in meinen Augen auch Hotwired aus dem Rails-Ökosystem völlig aus, und für statische Seiten ist auch Astro vollkommen ausreichend.

[GN⁺]

Hacker-News-Kommentare

• SPAs sind sinnvoll, wenn Nutzer lange Sitzungen in einer App verbringen, also in einer Struktur, bei der einmal ein großes Bundle geladen wird und die App danach nur noch mit kleinen Netzwerkanfragen nutzbar ist; sanfte Übergangseffekte sind nur ein Bonus und nicht das eigentliche Problem, das SPAs lösen. Die Behauptung, Client-seitiges Routing diene für Seitenübergänge, missversteht den Zweck von SPAs. Wenn man SPA auf Basis dieser falschen Annahme eingesetzt hat, dann hat dieser Artikel zwar recht, aber SPAs sind in der jQuery-Ära für komplexe Apps entstanden. Damals gab es riesige jQuery-Codeklumpen, bei denen jede div wie eine Mini-App funktionierte und mit vielen kleinen Netzwerkanfragen synchronisiert wurde. In alten Browsern und bei langsamen Internetverbindungen konnte man so effizient arbeiten, ohne jedes Mal den gesamten Code neu zu laden. Später haben Frameworks wie React die strukturierte App-Entwicklung vereinfacht, und der zentrale Vorteil von SPA ist, für Nutzer mit langen Sitzungen einmal ein großes Bundle zu cachen und danach den Netzwerkverkehr zu minimieren.

  • (Zitat aus dem obigen Kommentar: "...if you shared that misunderstanding of SPAs and used them to solve the wrong problem, this article is 100% correct.") Dem stimme ich vollkommen zu. Der Autor ist ein SEO-Berater und scheint sich nur auf Marketing-Websites zu konzentrieren. Echte Apps (nicht Marketing-Websites) können stark von SPA profitieren. Wenn man sich zum Beispiel vorstellt, Google Maps ohne SPA zu bauen, würde sich die UX schon allein mit hinzugefügten Seitenwechsel-Animationen massiv verschlechtern.

  • Da steht die Formulierung „nur jQuery-Spaghetti aufgestapelt“, aber ich habe tatsächlich frühe JS-Design-Patterns wie IIFE eingesetzt, um Code zu strukturieren, Module verzögert zu laden und Code zu obfuskieren. Und meiner Erfahrung nach war AngularJS der größte Versuch, Frontends zu strukturieren; für Java-Entwickler war es gerade wegen Modularisierung, DI und Testbarkeit attraktiv. Als ich anfangs Apps mit Backbone gebaut habe, dachte ich, dass der Großteil der Funktionalität im Backend liegen würde, deshalb habe ich Tests kaum beachtet. Später, beim Rebuild mit AngularJS, gab es deutlich mehr Frontend-Tests. Natürlich habe ich heute eine Abneigung gegen die Weitschweifigkeit, Komplexität und Indirektheit von modernem Angular-Code oder Java-Code.

  • Ich denke, eine langsame Netzwerkverbindung und aggressives Caching sind einer der stärksten Gründe für SPA-Bedarf, besonders bei Anwendungen und weniger bei Websites. Wenn es einmal eine ordentliche Verbindung gibt, kann man das komplette Frontend auf einmal laden und cachen, und die spätere Nutzung ist dann mit minimaler Bandbreite möglich.

  • Wenn man irgendwo arbeitet, wo moderne CI/CD-Pipelines verwendet werden, dann wird dieses große JS-Bundle bei mehreren Deployments pro Tag wahrscheinlich immer wieder neu gebaut, wodurch der Cache ungültig wird. HTTP2 ist seit zehn Jahren Standard im Browser, und dank Multiplexing gibt es keinen Grund mehr, JS in große Bundles zu packen. Der SPA-Ansatz mit großen Bundles nutzt moderne Fähigkeiten von Browsern und Servern nicht aus.

  • Ich frage mich, wie viele reale Fälle es wirklich gibt, in denen Netzwerkanfragen nach dem Laden tatsächlich sehr klein werden. Die meisten SPAs, die ich erlebt habe, hatten auch nach dem Laden noch viele große Requests und waren einfach viel langsamer, als HTML direkt auszuliefern. Die Behauptung, JSON sei magically besser komprimierbar als HTML, stimmt auch nicht. HTML lässt sich ebenfalls sehr gut komprimieren. Tatsächlich kommt mir das Argument, SPA sei wegen Netzwerkaspekten besser, fast wie Propaganda oder Aberglaube vor.

• Ich denke, der Wert von SPA liegt nicht nur in sanften Übergängen, sondern auch darin, dass der größte Teil der User Journey auf der Client-Seite verarbeitet wird und man sich um den Server kaum kümmern muss. Ein Beispiel: Selbst 2025 nervt es mich, dass die meisten Online-Shops bei jeder Filteränderung oder beim Wechsel in eine Kategorie die komplette Seite neu laden und die Daten erneut abrufen müssen. Wenn Nutzer zwischen Kategorien wechseln und mehrfach Anfragen auslösen, wäre die UX viel besser, wenn der gesamte Katalog einmal an den Client übertragen würde und man danach ohne Kommunikation mit dem Server filtern könnte. Natürlich könnte man einwenden, dass die Datenmenge groß sei, aber die meisten Shop-Kategorien passen in ein paar KB und sind kleiner als ein einzelnes Produktfoto. Ich baue solche Apps seit 2005 und verstehe bis heute nicht, warum diese UX nicht viel weiter verbreitet ist.

  • Meiner Meinung nach ist beim Full Reload nicht die Datengröße das größte Problem, sondern die Effizienz der Website. Die eigentlichen Daten sind nur ein paar KB, aber die Seite selbst lädt 100 MB herunter und der Browser verbraucht 1 GB RAM. Hacker News zum Beispiel lädt bei der Navigation meist neu und funktioniert selbst auf alten Laptops gut. Eine SPA wie DoorDash dagegen brauchte auf demselben Gerät 30 Sekunden, und bis zur eigentlichen Essensbestellung vergingen mehr als 3 Minuten. Allein bis die Oberfläche erschien, musste ich 2,5 Minuten warten, und das meiste davon war nicht einmal Full Reload.

  • Tools wie HTMX lösen viele dieser Probleme. Ich denke, der SPA-Ansatz führt letztlich dazu, dass man zwei Apps baut, ein Frontend und ein Backend. Für besser halte ich es, das meiste serverseitig zu erledigen und auf der Client-Seite nur einfache interaktive Effekte hinzuzufügen (anzeigen/verstecken, aufklappen/einklappen, Effekte usw.). Natürlich gibt es auch Bereiche, in denen SPA nützlich ist.

  • Eine ähnliche Erfahrung: Einige persönliche Projekte hoste ich auf statischen Webservern. Statt Zehntausende einzelne Seiten zu rendern, rendere ich im Client mit einer einzigen JSON-Datei in einer SPA. Ich habe auch GitHub Pages verwendet. In letzter Zeit experimentiere ich mit einer Struktur, bei der ich einen sqlite-Datenbank-wasm-Build nutze und per HTTP Range Requests nur die benötigten Seiten abrufe. sqlite Full Text Search funktioniert auch, aber bei kurzen Suchanfragen muss man die ganze Tabelle holen, was schade ist. Vielleicht ist es besser, die komplette DB herunterzuladen und die FTS-Tabelle lokal zu erzeugen.

  • Es gibt auch Gegenbeispiele. Wenn man zum Beispiel die Kategorie „sci-fi“ per Shift-Klick in einem neuen Tab öffnen will, funktioniert das in einer MPA ohne großen Aufwand, in einer SPA muss man das separat behandeln, was lästig ist. Wenn es keine Kategorielinks gibt und der Zugriff nur über eine Select Box läuft, ist die UX schlecht.

  • Im Allgemeinen wollen Unternehmen nicht, dass Nutzer den gesamten Katalog herunterladen, weil Konkurrenten ihn dann leicht analysieren können. Außerdem gibt es Fälle wie den Buchverkauf mit Hunderttausenden Titeln, bei denen es aus Sicht von UX, Bandbreite und Speicher ineffizient wäre, alles auf einmal zu übertragen.

• Der Zweck von SPA ist absolut nicht der Seitenübergang. Es gibt kaum SPAs, die gute Seitenübergänge wirklich ordentlich umsetzen. In Next.js ist das wegen der Art des Root-Loadings nahezu unmöglich. Ich habe tatsächlich einmal versucht, in Next.js ordentliche Page Transitions einzubauen, und das war ein kompletter Albtraum. Ich sehe zwei klare Vorteile von SPA. Erstens wollen die meisten Apps ein gewisses Maß an Interaktivität, weil HTML/CSS allein nicht reicht, und React mit reinem HTML zu mischen ist sehr schmerzhaft, besonders wenn globales State-Management nötig ist. Zweitens lädt man, wenn die gesamte Seitenstruktur vorab geladen ist, spätere Daten schneller, und sofortige Reaktion plus Loading Screen nach dem Klick ist UX-seitig besser als eine Reaktion erst 500 ms später — unter 100 ms ist es natürlich etwas anderes. Da nicht die ganze Seite neu gezeichnet werden muss, ist die Frontend-Performance etwas, das reines HTML nicht erreicht. Es gibt Beispiele wie Basecamp, die komplexe Web-Apps ohne SPA gut gebaut haben, aber schon nach 30 Sekunden Herumklicken merkt man, dass sie nicht an die SPA-Performance herankommen. Ich wünsche mir, dass das Web sich webtypisch verhält, aber die zusätzliche Komplexität von Next.js und SPA hat Apps zwar schneller und reaktionsfähiger gemacht, gleichzeitig aber auch die Entwicklung mühsamer und große Bundles zum Problem gemacht. Trotzdem glaube ich, dass HTML allein die Performance von SPA noch nicht erreicht.

  • 3. Es gibt auch eine API-Perspektive. Wenn es bereits iOS-/Android-Apps oder eine API für Entwickler gibt, dann fügt eine SPA diesem Backend einfach noch eine weitere App hinzu, was die Integration erleichtert.

• Ich weiß nicht, in welchem Universum der SEO-Berater lebt, der diesen Artikel geschrieben hat. Next und Nuxt als repräsentative Frameworks zu nennen, die im Gegensatz zu SPA stehen, ist völlig falsch. 1. Next hat die USA bzw. den Westen fast komplett übernommen, und wenn von einer neuen React-App die Rede ist, ist meist Next gemeint. Im Vue-Ökosystem ist Nuxt fast Standard, Nuxt = das Next der Vue-Welt. Das heißt: Die Leute wählen unbewusst bereits Next und damit eine MPA-Strategie. Das Pendel ist viel zu stark in Richtung MPA ausgeschlagen, deshalb sollte man eher dazu raten, einmal SPA zu versuchen. Die letzten acht Jahre waren eine Boomphase für MPA, und inzwischen empfiehlt sogar Facebook in der offiziellen Doku Next statt Create React App. 2. Beschwerden über die Komplexität von Next sind Beschwerden über die Schwierigkeit der aktuellen MPA-Strategie; die SPA-Seite ist erzählerisch seit fast zehn Jahren stehen geblieben. 3. MPA-Entwicklung ist viel schwieriger als SPA-Entwicklung, weil man die Trennung zwischen Server und Client viel strenger einhalten muss. 4. Wenn man in einer SPA Daten im MPA-Stil laden will, ist das die Entscheidung des Entwicklers, und Vor- und Nachteile muss er selbst tragen. Man kann Daten auch vorab laden und SPA-Navigation dadurch sofortig machen. 5. Neben dem Haupt-Frontend, bei dem SEO wirklich wichtig ist, gibt es noch viel mehr interne Dashboards und Apps. React-Entwickler arbeiten oft genau dort, deshalb ist es wichtig, sich nicht unnötig Ballast aufzubürden, nur weil man den ersten Frame um jeden Preis perfekt ausliefern will.

  • Ich frage mich, ob es diesen „Krieg“ überhaupt je gab. Zu sagen, Next habe gewonnen, ist fast dasselbe wie zu sagen, React habe gewonnen. Eigentlich hat niemand gewonnen; alle laufen nur dem Mainstream hinterher. Wer bei Angular oder einem minimalistischen beziehungsweise frameworklosen Entwicklungsstil geblieben ist, denkt wahrscheinlich nur: „Wovon reden die eigentlich alle?“ Und die Startup-Szene und das Silicon Valley bewerben sich gegenseitig und schmieden Allianzen, ohne dass das in Wirklichkeit so großartig wäre. Next mag vielleicht nicht besonders gut sein, aber weil Karriere und Identität vieler Menschen inzwischen daran hängen, verschwindet es nicht so leicht.

• Ich halte den abwertenden Ton gegenüber SPA für unfair. SPA erfordert definitiv mehr Aufwand, bietet aber eindeutig auch mehr Vorteile. Lange Zeit war SPA der einzige Weg, eine UX zu bauen, die sich wie eine App anfühlt. Der Autor spricht zwar von App-Müdigkeit, aber wenn man wirklich eine „Application“-Erfahrung liefern will, ist SPA fast der einzige Weg. Einen schweren SPA-Stack mit einer leichten Website bzw. statischen Site zu vergleichen, ist unangebracht. Wer eine leichte Website bauen kann, kann auch eine leichte SPA bauen. Wenn man ineffizient baut, wird es in beiden Fällen langsam und schwer. Als jemand, der viel in SPA investiert hat, interessiere ich mich sehr für Wege, mit weniger Aufwand dieselbe Erfahrung zu erreichen, aber dieser Artikel wirkt eher wie ein bisschen visuelle Kosmetik. Die Policy ist wertvoll, aber meiner Meinung nach nicht einflussreich genug, um die Entscheidung SPA oder nicht-SPA zu bestimmen.

  • Mich würde interessieren, worauf sich die Behauptung „aber besser“ eigentlich stützt.

• „Versuch mal, linear.app ohne SPA-Framework zu bauen“ ist eine unrealistische Forderung, und die These „Native CSS transitions haben den größten Vorteil von SPA (Client-Routing) zerstört“ ergibt keinen Sinn.

  • Ich denke, Linear ist selbst unter SPAs ein sehr besonderer Fall. Es geht nicht darum, SPA zu verbieten oder JS komplett aus dem Browser zu entfernen. Linear ist schnell wegen seines „offline-first“-Designs, aber nur sehr wenige Dienste arbeiten so. Für Ticketing, Foren, News, Blogs und informationsorientierte Sites ist SSR-basierte Entwicklung meiner Meinung nach viel besser. Man sollte SPA nur dort einsetzen, wo sie wirklich nötig ist, und den Rest mit SSR schnell entwickeln und per CSS wie SPA aussehen lassen — das ist viel effizienter.

  • SPA hat schon ihren Platz, aber die übrigen 99 % der Websites müssen keine SPA sein.

• Bei SPA geht es nicht um View Transitions bzw. Seitenübergänge. Der Originaltext (TFA) deutet an, dass auffällige Übergänge zwischen Seiten wichtig seien, was falsch ist. Statt „CMO“ oder „Brand Manager“ die Schuld zu geben, sollte man den eigentlichen Wert von SPA beleuchten. SPA ist ein hervorragendes Framework für Client-Logik, für die Trennung der Zuständigkeiten (Frontend-Logik und Backend getrennt), für eine bessere Developer Experience und damit schnellere Entwicklungsgeschwindigkeit. Solche Artikel tauchen oft auf, weil sie wie mein Kommentar strukturiert sind, also Streit fördern, aber ich finde nicht, dass dieser Text eigentlich so viel Aufmerksamkeit verdient.

  • Solche Themen verbreiten sich wohl, weil sie Trendcharakter und Wiederholung haben, was auch perfekt dazu passt, dass sich der Autor des Originals auf SEO konzentriert. Ich habe viele SPAs gebaut, die überhaupt keine Seitenübergänge hatten. In letzter Zeit habe ich dank View Transitions zwar Übergangseffekte eingebaut, aber sie waren nie zwingend erforderlich.

• Aus meiner Sicht war das zentrale Versprechen von SPA nie sanfte Übergänge, sondern die Erstellung einer vollständig vom Backend getrennten Daten-API und eines Frontends. Deshalb mag ich es nicht, SSR und Client-Rendering zu mischen. Es sollte entweder eine Website oder eine App sein.

• Ich frage mich: Was ist überhaupt das Kriterium für SPA und MPA? Meine persönliche Website auf Basis von Next.js rendert in Wirklichkeit fast alles serverseitig. Technisch gesehen ist sie eine SPA, aber wenn JS aktiviert ist, funktionieren RSC und Client-seitige Navigation, und wenn JS deaktiviert ist, werden Client-only-Komponenten (z. B. ein QR-Code-Generator) als Fallback-Inhalt angezeigt, während der Rest vollständig per SSR gerendert wird; etwas langsamer, aber es funktioniert gut. Komponenten nicht auf dem Server zu rendern, ist sogar aufwendiger. Progressive Enhancement ist das Beste.

  • Das „Kriterium für SPA und MPA“ kann man danach beurteilen, wie oft beim Laden einer App das Window load-Event ausgelöst wird.

• Mich frustriert auch, dass die SEO-Branche oder neue Webentwickler, die nach Corona eingestiegen sind, SPA ständig missverstehen und abwerten. Aus meiner Sicht als jemand, der seit den 2000ern entwickelt, liegt der wahre Ursprung von SPA nicht in dem im Originaltext erwähnten „falschen Versprechen“, sondern darin, dass sich Ende der 2000er und Anfang der 2010er mit der Verbreitung von Mobile-first-Strategien Frontend und Backend vollständig trennen mussten. Vorher bestand Frontend meist nur aus serverseitig per Template erzeugtem HTML mit etwas jQuery oben drauf. Heute müssen Mobile- und Desktop-Apps dieselbe Business-Logik und dieselbe DB nutzen, weshalb REST-Strukturen, Roy Fieldings Arbeiten, serviceorientierte Architektur und die externe Bereitstellung von APIs zum Mainstream wurden. Auch Kostenoptimierung spielte eine Rolle. In dieser Zeit gerieten Full-Stack-Web-Frameworks wie Ruby on Rails oder Django vorübergehend ins Stocken. Mit dem Aufstieg von Node.js wurden Browser und mobile Geräte immer leistungsfähiger, sodass viel Business-Logik auf „Edge Devices“, also den Client, verlagert werden konnte. Genau das ist der Kern von SPA. CSS kann diesen Bedarf meiner Meinung nach nicht ersetzen.