Warum eine Single Page App nicht immer die beste Wahl für deine Website ist

Zwei Zeitalter der Web-Entwicklung

MVC

Ein wichtiger Meilenstein in den 90er Jahren bestand im MVC Konzept, d.h. Model View Controller. Dabei handelt es sich um eine Best Practice zur Strukturierung von Web-Backends. Auf dieser Idee basieren viele Frameworks, wie Django (Python), ASP.NET (C#) oder Laravel (PHP).

Sie haben alle gemeinsam, dass du einen Server mietest, das Framework darauf installierst und darin dein Web-Projekt entwickelst. Öffnet ein Nutzer deine Website wird in dem Moment der Server angefragt, er baut die angefragte Seite live zusammen, und antwortet mit der fertigen Seite.

Ein Nachteil ist hierbei, dass jeder Seitenwechsel wieder eine neue Server-Anfrage erfordert, sodass zwischendurch die neue Seite laden muss. Man hat nicht dasselbe flüssige Gefühl wie bei einer nativen Desktop Anwendung, beispielsweise Microsoft Word. Die Anforderung auch komplexe Web-Anwendungen mit hoher Nutzerfreundlichkeit zu schaffen, wie z.B. Gmail, führte dazu, dass sich Single Page Apps etablierten.

Single Page Apps

Single Page Apps basieren auf Frameworks wie Angular, React, Vue, Svelte oder Solid. Sie verwenden die Idee, dass Nutzer beim ersten Seitenaufruf nicht die eine aufgerufene Seite geliefert bekommen, sondern stattdessen einen Baukasten. Dieser Baukasten versetzt den Browser des Nutzers in die Lage alle Seiten der Website zu bauen.

Navigiert der Nutzer nun zwischen den einzelnen Seiten der Website, findet meist gar keine Kommunikation mit einem Server statt, sondern der Browser des Nutzers baut sich selbst die nun aufgerufene Seite zusammen.

Die Konsequenz ist eine absolut flüssige Navigation ohne zeitlichen Versatz und dadurch eine verbesserte Nutzererfahrung. Eine negative Konsequenz ist allerdings, dass der erste Seitenaufruf erheblich länger dauert, weil viel mehr Daten (nämlich der ganze Baukasten) heruntergeladen werden muss.

Hydration oder MPA mit Islands

Wir stellen also fest, dass man sich entscheiden muss zwischen zwei Lösungen, die beide ihre Nachteile haben:

• MVC bietet einen schnelleren ersten Seitenaufruf, aber erfordern immer auch Aufrufe aller weiteren Seiten.
• Single Page Apps bieten einen langsamen ersten Seitenaufruf, aber einen schnelleren Aufruf aller weiteren Seiten.

Optimal wäre es, wenn man beide Vorteile genießen könnte. Und damit bewegen wir uns in die dritte Era der Web-Entwicklung, hin zu zwei Lösungsansätzen, die sich parallel entwickelt haben.

Hydration

Ausgehend von den bekannten Frameworks für Single Page Apps wurde folgende Lösung entwickelt. Die Idee ist, den ersten Seitenaufruf dadurch zu verkürzen, dass man bereits auf dem Server, noch bevor der Nutzer die Seite aufruft, die gesamte Website baut. Also vereinfacht gesagt soll der Server die Website aufrufen und jede Seite abspeichern.

Ruft nun ein Nutzer die Seite auf, wird ihm direkt die gespeicherte Seite zugeschickt. Nun könnte man sagen, das sei ja wieder genau wie beim MVC-Konzept. Allerdings muss man bedenken, dass hier kein Computer die Seite neu generieren muss. Sie ist ja schon gespeichert und muss nur noch verschickt werden. Somit sind wir hier erstmal schneller.

Der Nutzer bekommt nun also beim ersten Seitenaufruf die fertig gespeicherte Seite zusammen mit dem Baukasten, d.h. dem Framework und dem Code, den er braucht, um dieselbe Seite im Browser zu generieren. Sobald der Nutzer die gespeicherte Seite geladen hat, kann er sie schon sehen. Allerdings ist die Seite dann noch nicht interaktiv.

Nun springt das Single Page App Framework an, baut die Website auf dem Browser des Nutzers zusammen und kombiniert sie mit der bereits zuvor gespeicherten Version der Website. Dieser Prozess heißt Hydration.

Während die bekannten JavaScript Single Page App Frameworks wie React und Vue diese Funktion anbieten, haben sich auf dieser Basis neue Frameworks etabliert. Diese machen die Entwicklungserfahrung deutlich angenehmer. Beispiele sind Next.js, Nuxt.js, Gatsby, Quasar, Gridsome, und viele mehr.

Insgesamt hat Hydration zwar den Vorteil, dass der Nutzer die Seite schon früher sehen kann. Aber deutlich schneller interaktiv wird die Seite nicht. Und es ist weiterhin trotzdem nötig den gesamten Baukasten mitzuschleifen. Anders ausgedrückt: Das gesamte Single Page App Framework muss mit zum Nutzer gesendet werden, und ist streng genommen ja unnötiger Ballast.

MPA und Islands

Aus dieser Idee der radikalen Optimierung entsprangen mehrere Frameworks, die einen ganz anderen Weg gehen. Marko, ein Framework von eBay, verfolgt diesen Weg schon am Längsten - und das konsequent entgegen den damaligen Mainstream, der sich ignorant in Richtung Single Page Apps bewegt hat. Mit großen Ähnlichkeiten zu React verfolgt Qwik dasselbe Ziel, genauso wie auch Elder und zu guter Letzt Astro.

Der Grundgedanke dieser Lösungen ist, dass man keinen unnötigen Ballast an den Nutzer senden möchte, und dass man trotzdem nur fertig gespeicherte Seiten senden möchte. Das beste aus allen Welten.

Trotz der scheinbaren Nachteile geht man nun wieder zurück zu einer MPA, d.h. Multi Page App. Wie es ja ursprünglich schon beim MVC System war, muss nun wieder zwischen den Seiten-Navigationen der Server angefragt werden. Da in diesem Fall aber nur fertig gespeicherte Seiten geladen werden - und diese sogar von einem CDN wie Cloudflare bereitgestellt werden können - ist es gar nicht mehr so schlimm wie damals.

Hinzu kommt, dass man nur das absolute Minimum an JavaScript Code an den Nutzer sendet. Zur Erinnerung: Single Page Apps basieren auf sehr großen JavaScript Frameworks. Diese erfordern, dass große Datenmengen zum Nutzer gesendet werden und, dass viel Code im Browser des Nutzers ausgeführt werden muss. Diesen ganzen Overhead möchte man sich sparen, indem man nur diejenigen JavaScript-Code-Schnipsel lädt, die wirklich für die Interaktionen des Nutzers auf der jeweiligen geladenen Seite von Belang sind.

Die Konsequenz ist, dass Seiten immer so schnell laden, wie es konzeptionell maximal möglich ist. Und der Wechsel zwischen einzelnen Seiten ist dadurch auch so schnell, dass man es kaum merkt. Verglichen mit aufgeblähten Single Page Apps ist es sogar oftmals deutlich schneller, obwohl es sich um eine Multi Page App handelt.

Das richtige Werkzeug für den richtigen Zweck

Zusammenfassend muss man sagen, dass es für vollwertige Web Apps, die im eigentlichen Sinne einer Applikation funktionieren, dennoch die bessere Lösung ist, ein Single Page App Framework als Grundlage zu verwenden. Das betrifft beispielsweise eine App wie das bereits erwähnte Gmail, deren Eigenarten sich eher wie eine Desktop-App verhalten als wie eine klassische Website.

Im Gegensatz dazu, sollte man sich beim Bau einer durchschnittlichen Website nicht von der weiten Verbreitung von Single Page Apps blenden lassen. Besonders wenn SEO relevant ist, muss man sich für eine bessere Alternative entscheiden. Dann sollte man sich im Kontext von modernen MPA frameworks umschauen.

Marko, Qwik, Elder und Astro haben auch deutliche Unterschiede. Dieser Artikel beschreibt einige Details und dieser Artikel beschreibt warum eine Single Page App vielleicht doch gar nicht so gut ist.