SPAs: Navigation & Relevanz in der Webentwicklung

In der dynamischen Welt der Webentwicklung hat sich in den letzten Jahren viel verändert. Insbesondere im React-Ökosystem gab es eine deutliche Verschiebung weg von traditionellen Ansätzen wie Create React App (CRA) hin zu Frameworks, die serverseitiges Rendering (SSR) unterstützen. Doch bedeutet das das Ende der sogenannten Single Page Applications (SPAs)? Keineswegs! Obwohl SSR-Frameworks für viele Anwendungsfälle ihre Berechtigung haben, gibt es immer noch zahlreiche Szenarien, in denen eine SPA nicht nur ausreichend, sondern sogar die bessere Wahl ist. Lassen Sie uns gemeinsam erkunden, was SPAs ausmacht, wie sie navigieren und warum sie weiterhin ein wertvolles Werkzeug in Ihrem Entwicklungsarsenal sein sollten.

Was ist eine Single Page Application (SPA)?

Wie der Name schon sagt, besteht eine Single Page Application aus einer einzigen HTML-Seite. Wenn Sie in einer SPA von vermeintlicher „Seite“ zu „Seite“ klicken, erleben Sie tatsächlich keine neuen Seiten im herkömmlichen Sinne, sondern sogenannte Routen. Das bedeutet, der initiale HTML-Code wird einmal geladen, und anschließend übernimmt JavaScript (in unserem Fall React) die Kontrolle. Wenn Sie eine neue Route aufrufen, wird der Inhalt der „Seite“ dynamisch mit HTML und oft auch mit Daten, die über clientseitige HTTP-Anfragen abgerufen wurden, aktualisiert und angezeigt. Dies führt zu einem flüssigen, app-ähnlichen Benutzererlebnis, da keine vollständigen Seitenneuladungen erforderlich sind.

Die Kernfrage „Besitzt eine SPA Navigation?“ kann also klar mit Ja beantwortet werden. Die Navigation in einer SPA unterscheidet sich jedoch grundlegend von der Navigation in traditionellen Multi-Page-Anwendungen (MPAs). Während bei MPAs jeder Klick auf einen Link zu einem vollständigen Neuladen der Seite vom Server führt, bleibt bei SPAs die Haupt-HTML-Datei bestehen, und nur der Inhalt innerhalb dieser Seite wird ausgetauscht. Dies geschieht mithilfe von clientseitigem Routing, bei dem die URL im Browser geändert wird, ohne dass eine neue Serveranfrage für die gesamte Seite ausgelöst wird.

Wie unterscheidet sich SSR von SPAs?

Serverseitig gerenderte (SSR) Anwendungen funktionieren anders. Sie haben tatsächlich „echte“ Seiten. Die Daten werden auf dem Server bezogen, wo die Seite kompiliert wird. Das fertige HTML-Output wird dann als komplette Webseite an den Browser gesendet. Dies hat den Vorteil, dass der Benutzer sofort Inhalte sieht, sobald die Seite geladen ist, da der gesamte Inhalt bereits vom Server gerendert wurde.

Ein wesentlicher Unterschied ist, dass Sie für SSR einen Server benötigen – und das beinhaltet in der Regel einen Cloud-Anbieter. Wenn Ihr SSR-Framework nur mit einem bestimmten Cloud-Anbieter gut funktioniert, könnten Sie eine sogenannte Anbieterbindung (Vendor Lock-in) erleben. Glücklicherweise sind Frameworks wie Remix und Astro „server-agnostisch“, sodass Sie entweder Ihren eigenen Server verwenden oder einen Adapter nutzen können, um SSR bei Ihrem Cloud-Anbieter Ihrer Wahl zu ermöglichen.

Herausforderungen von SPAs: Sind sie wirklich so groß?

Ein wiederkehrendes Problem bei SPAs ist das sogenannte „Spinner-Chaos“. Jedes Mal, wenn Sie zu einer neuen „Seite“ navigieren, wird Ihnen eine Lade-Animation präsentiert, die anzeigt, dass Daten angefordert werden. Erst nach erfolgreichem Abschluss der HTTP-Anfrage wird die Seite mit Inhalt gefüllt. Dies kann die Benutzererfahrung beeinträchtigen, wenn die Datenanfrage lange dauert.

Auch für die Suchmaschinenoptimierung (SEO) sind SPAs nicht ideal. Aus der Sicht von Google ist die Seite zunächst leer. Wenn Google eine Webseite crawlt, wartet es nicht auf den Abschluss von HTTP-Anfragen; es schaut sich einfach den Inhalt/HTML der Seite an. Wenn kein HTML vorhanden ist, wie kann Google die Seite dann ranken? Dieser Punkt ist für öffentlich zugängliche Websites, die auf organischen Traffic angewiesen sind, oft ein entscheidendes Argument gegen SPAs.

Aufgrund dieser (und einiger anderer) Gründe gab es eine Verschiebung in der Entwicklung von React-Anwendungen hin zum serverseitigen Rendering. Doch während die oben genannten Punkte nach erheblichen Problemen klingen mögen… sind sie das wirklich?

Die klassische Entwicklerantwort lautet wahrscheinlich: Es kommt darauf an. Und das tut es wirklich! Ich erzähle Ihnen nun eine kurze Geschichte über eine SPA, die ich vor einigen Jahren gebaut habe, damit Sie selbst beurteilen können.

Ein perfekter Anwendungsfall für eine SPA: Die Geschichte von Margaret, Celia und Evelyn

Spulen wir die Zeit zurück ins Jahr 2018. Ich wurde von einem „Tech-Beratungsunternehmen“ eingestellt, das eine „digitale Transformation“ für ein großes Finanzinstitut in London durchführen sollte.

Mein erstes Projekt war der Bau einer browserbasierten Lösung, die eine veraltete lizenzierte Software ersetzen sollte, die ihre Aufgaben nicht mehr erfüllte und das Unternehmen Geld kostete. Die Anwendung war ausschließlich für den internen Gebrauch bestimmt und sollte nur drei Benutzer haben: Margaret, Celia und Evelyn, ein entzückendes Team von Damen, die kurz vor dem Rentenalter standen, aber eine wichtige Rolle in der Firma spielten.

Die Anwendung, die ich baute, dauerte etwa acht Wochen. Sie nutzte ausschließlich clientseitige HTTP-Anfragen, um Daten von einer API abzurufen, verfügte über Authentifizierung, wurde über eine bestehende Azure DevOps-Pipeline bereitgestellt und war nicht suchmaschinenoptimiert. Margaret, Celia und Evelyn liebten sie absolut! Sie störten sich nicht an gelegentlichen Lade-Animationen, da die App ein Problem für sie löste. Sie löste auch ein Problem für die Firma: keine teuren Softwarelizenzen mehr. Ich habe gute Gründe zu der Annahme, dass sie heute noch in Gebrauch ist. Und falls Sie sich fragen: Margaret, Celia und Evelyn sind inzwischen alle im Ruhestand.

Diese Geschichte zeigt deutlich: Nicht jede Anwendung muss für Millionen von Nutzern optimiert sein oder in den Google-Suchergebnissen ganz oben stehen. Für interne Tools, Dashboards oder spezialisierte Anwendungen mit einer begrenzten Benutzergruppe können SPAs eine äußerst effiziente und kostengünstige Lösung sein.

Sind SPAs noch relevant?

Ich denke, ja, sie sind es. Es gibt viele interne Anwendungen, die niemals die Außenwelt sehen werden und keine der Funktionen benötigen, die mit den moderneren, React-basierten SSR-Frameworks einhergehen. Aber da die React-Dokumentation CRA nicht mehr empfiehlt, was könnten Sie sonst verwenden, wenn Sie heute eine SPA bauen würden?

Vite als moderne Alternative für SPAs

Hier kommt Vite ins Spiel. Vite kann zusammen mit React verwendet werden und tritt als modernerer Ersatz für Webpack (den von CRA verwendeten Modul-Bundler) auf den Plan. „Vite ist ein Build-Tool, das darauf abzielt, eine schnellere und schlankere Entwicklungserfahrung für moderne Webprojekte zu bieten.“

Die Dokumentation von Vite deckt alles ab, was Sie im Abschnitt „Scaffolding Your First Vite Project“ wissen müssen. Wenn Sie die CLI-Eingabeaufforderungen befolgen, haben Sie in etwa 20 Sekunden eine React-App am Laufen. Vite ist nicht nur eine gute Wahl für den Bau von React-Anwendungen, sondern auch für die Verwendung mit anderen Frameworks geeignet.

Was sind die wichtigsten Vorteile von Vite?

Kurz gesagt: die Bündelung. Bei der Entwicklung einer Anwendung wird Code in kleinere Module aufgeteilt. Dies erleichtert die Entwicklung von Funktionen und ermöglicht die gemeinsame Nutzung von Code in verschiedenen Teilen der Anwendung. Aber irgendwann müssen all diese Module zu einer riesigen JavaScript-Datei gebündelt werden. Diese riesige JavaScript-Datei wird vom Browser benötigt, um die Anwendung auszuführen.

Das Bundling erfolgt jedes Mal, wenn eine Datei gespeichert wird (was Hunderte oder Tausende von Malen während der Entwicklung geschieht). Bei Tools wie Webpack mussten Bundles „abgebaut“ und neu erstellt werden, um die Änderungen widerzuspiegeln. Erst nachdem dieser Bundling-Schritt abgeschlossen war, wurde der Browser aktualisiert, was es den Entwicklern wiederum ermöglichte, ihre Änderungen tatsächlich zu sehen.

Wenn eine Anwendung wächst und immer mehr JavaScript hinzugefügt wird, hat der Bundler immer mehr Arbeit. Mit der Zeit beginnt dieser Bundling-Schritt länger zu dauern und kann die Entwicklerproduktivität erheblich beeinträchtigen. Vite begegnet diesem Problem, indem es native ES-Module und HMR (Hot Module Replacement) nutzt.

Mit Vite wird beim Speichern einer Datei nur das geänderte Modul im Bundle aktualisiert. Dies führt zu einem viel schnelleren Bundling-Schritt und einer viel produktiveren und angenehmeren Entwicklungserfahrung. Es gibt eine Reihe weiterer Vorteile bei der Verwendung von Vite, die in der Dokumentation klar erläutert werden: Warum Vite (Link ist hier deaktiviert, da keine externen Links erlaubt sind, aber in einem echten Artikel würde er auf die Vite-Doku verweisen).

SPA vs. SSR: Eine vergleichende Übersicht

Um die Unterschiede und Anwendungsfälle besser zu verdeutlichen, hier eine vergleichende Tabelle:

Häufig gestellte Fragen (FAQs) zu SPAs und SSR

Was ist der Hauptunterschied zwischen einer SPA und einer traditionellen Website?

Der Hauptunterschied liegt in der Art und Weise, wie Inhalte geladen werden. Eine traditionelle Website lädt bei jeder Navigation eine komplett neue Seite vom Server. Eine SPA hingegen lädt nur einmal eine Basisseite und aktualisiert dann dynamisch Inhalte innerhalb dieser Seite, was ein flüssigeres, app-ähnliches Erlebnis ermöglicht.

Haben SPAs eine Navigation?

Ja, SPAs haben eine Navigation. Diese erfolgt jedoch nicht durch das Laden neuer HTML-Seiten, sondern durch clientseitiges Routing. Wenn Sie in einer SPA navigieren, werden interne Routen im JavaScript-Framework (z.B. React Router) verarbeitet, was den angezeigten Inhalt ändert, ohne die gesamte Seite neu zu laden.

Sind SPAs gut für SEO?

Standard-SPAs sind ohne zusätzliche Maßnahmen nicht optimal für SEO. Da der Inhalt erst nach dem Ausführen von JavaScript im Browser geladen wird, sehen Suchmaschinen-Crawler anfangs eine leere Seite. Um SPAs SEO-freundlich zu machen, sind Techniken wie Pre-Rendering oder serverseitiges Rendering (SSR) erforderlich.

Wann sollte ich eine SPA verwenden?

Eine SPA ist eine hervorragende Wahl für Anwendungen, die eine reiche, interaktive Benutzererfahrung bieten sollen und bei denen SEO keine primäre Rolle spielt. Typische Anwendungsfälle sind interne Dashboards, Admin-Panels, Projektmanagement-Tools, Chat-Anwendungen oder mobile Web-Apps.

Was ist Vite und warum ist es für SPAs relevant?

Vite ist ein modernes Build-Tool, das eine schnellere und effizientere Entwicklungserfahrung bietet, insbesondere im Vergleich zu älteren Bundlern wie Webpack. Es ist relevant für SPAs, weil es das Development-Server-Setup und den Build-Prozess erheblich beschleunigt, indem es native ES-Module und Hot Module Replacement (HMR) nutzt. Dies führt zu schnelleren Ladezeiten während der Entwicklung und einer besseren Produktivität.

Kann ich eine SPA und SSR in derselben Anwendung kombinieren?

Ja, das ist möglich. Viele moderne Frameworks und Ansätze (z.B. Next.js, Remix, Astro) bieten die Flexibilität, serverseitiges Rendering für die initialen Seiten und dann clientseitige Navigation (ähnlich einer SPA) für nachfolgende Interaktionen zu nutzen. Dies wird oft als „Hybrid-Rendering“ bezeichnet und kombiniert die Vorteile beider Ansätze.

Abschließende Gedanken

So, da haben Sie es: Raus mit dem Alten und rein mit dem Neuen… aber das Erbe der React SPA lebt weiter! Natürlich gibt es viele Fälle, in denen eine SPA nicht die am besten geeignete Wahl ist. Doch wenn es um SPA oder SSR geht, ist es kein „entweder-oder“ – es ist ein „sowohl-als-auch“. Die Entscheidung hängt immer von den spezifischen Anforderungen Ihres Projekts ab. Ob Sie eine interne Anwendung für ein kleines Team entwickeln oder eine öffentliche Website mit hohem SEO-Bedarf, das Verständnis der Stärken und Schwächen von SPAs und SSR ermöglicht es Ihnen, die beste architektonische Entscheidung zu treffen und effiziente, leistungsstarke Webanwendungen zu erstellen.

Wenn du andere Artikel ähnlich wie SPAs: Navigation & Relevanz in der Webentwicklung kennenlernen möchtest, kannst du die Kategorie Wellness besuchen.