Frontend nach der SPA-Ära

Single Page Applications traten mit einem klaren Versprechen an: native App-Erlebnisse im Browser. Kein Seitenneuladen, fliessende Übergänge, sofortige Reaktion auf Nutzereingaben. Frameworks wie Angular, React und Vue machten dieses Versprechen umsetzbar und wurden zum Standard moderner Webentwicklung.

Das Versprechen wurde teilweise eingelöst. SPAs bieten eine flüssige Nutzererfahrung, sobald sie vollständig geladen sind. Doch dieses «sobald» ist das Problem.

Initiale Ladezeit: Eine typische SPA liefert beim ersten Aufruf ein JavaScript-Bundle von einem bis drei Megabyte an den Browser. Bevor der Nutzer etwas sieht, muss dieses Bundle heruntergeladen, geparst und ausgeführt werden. Auf einem aktuellen Smartphone mit guter Verbindung dauert das zwei bis vier Sekunden. Auf einem älteren Gerät mit mobiler Verbindung deutlich länger.

SEO: Suchmaschinen können JavaScript-gerenderte Inhalte indexieren – aber mit Einschränkungen und Verzögerung. Server-Side Rendering wurde nachträglich als Lösung für ein Problem eingeführt, das die Architektur selbst erzeugt hatte.

Accessibility: SPAs übernehmen die Kontrolle über Navigation, Fokus-Management und Seitenankündigungen. Diese Verantwortung wird regelmässig unzureichend umgesetzt. Screenreader-Nutzer erleben gebrochene Navigation, fehlende Seitenankündigungen und Fokus, der nach einem Routenwechsel ins Nirgendwo springt.

Komplexität: State Management, Routing, Build-Konfiguration, Code Splitting, Hydration – die Infrastruktur, die nötig ist, um eine SPA produktionsreif zu betreiben, übersteigt häufig die Komplexität der eigentlichen Geschäftslogik.

Das Ergebnis: Für hochinteraktive Anwendungen – Editoren, Dashboards, Echtzeit-Kollaboration – sind SPAs nach wie vor eine valide Architektur. Für die Mehrheit der Webanwendungen erzeugen sie Komplexität, die keinem Nutzer zugute kommt.

JavaScript ist die teuerste Ressource im Web. Nicht in der Dateigrösse – Bilder sind grösser – sondern in der Verarbeitungszeit. Ein Megabyte JavaScript belastet den Browser um ein Vielfaches mehr als ein Megabyte Bilder, weil es geparst, kompiliert und ausgeführt werden muss.

Die Konsequenzen sind messbar:

Core Web Vitals: Googles Metriken für Nutzererfahrung – Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS) – werden von JavaScript-lastigen Seiten systematisch verfehlt. Daten aus dem Chrome UX Report zeigen, dass Seiten mit weniger als 200 KB JavaScript drei- bis fünfmal häufiger alle Core Web Vitals bestehen als Seiten mit über einem Megabyte.

Geräteungleichheit: Entwickler testen auf aktuellen MacBooks und Flaggschiff-Smartphones. Die Mehrheit der Nutzer weltweit verwendet Geräte mit deutlich weniger Rechenleistung. Ein JavaScript-Bundle, das auf einem M3 MacBook in 200 Millisekunden verarbeitet wird, braucht auf einem drei Jahre alten Android-Gerät zwei Sekunden oder mehr.

Wartbarkeit: Jede Abhängigkeit im Frontend-Bundle ist eine potenzielle Quelle für Versionskonflikte, Sicherheitslücken und Breaking Changes. Das npm-Ökosystem ist berüchtigt für Dependency-Ketten, die hunderte von transitiven Abhängigkeiten umfassen. Ein einzelnes Update kann eine Kaskade von Inkompatibilitäten auslösen.

Fragilität: Client-Side JavaScript kann aus vielen Gründen fehlschlagen – Ad-Blocker, Unternehmensproxies, Browser-Erweiterungen, Netzwerkunterbrechungen. Eine Seite, die vollständig auf JavaScript angewiesen ist, wird bei einem Fehler vollständig unbenutzbar. Eine Seite, die HTML ausliefert und JavaScript als Enhancement nutzt, bleibt funktional.

Die Frage ist nicht, ob JavaScript im Frontend verwendet werden soll. Die Frage ist, wie viel JavaScript tatsächlich nötig ist – und ob der Server nicht den grösseren Teil der Arbeit übernehmen kann.

Server-Side Rendering ist keine neue Erfindung. Jede Webanwendung vor 2010 funktionierte so: Der Server generiert HTML, der Browser zeigt es an. Was sich geändert hat, sind die Werkzeuge – und die Möglichkeit, Server-Rendering mit gezielter Client-Interaktivität zu kombinieren.

Blazor Server-Side Rendering

Blazor SSR rendert Razor-Komponenten auf dem Server und liefert fertiges HTML an den Browser. Für interaktive Bereiche kann selektiv auf Blazor Server (SignalR) oder Blazor WebAssembly gewechselt werden – pro Komponente, nicht pro Seite. Das Ergebnis: schnelle initiale Ladezeiten, SEO-Kompatibilität und volle Interaktivität dort, wo sie gebraucht wird.

React Server Components

React Server Components ermöglichen es, Teile einer React-Anwendung auf dem Server auszuführen. Server-Komponenten haben keinen Client-Side-Footprint – sie senden reines HTML, kein JavaScript. Nur Komponenten, die tatsächlich Interaktivität benötigen, werden als Client-Komponenten markiert.

Astro

Astro verfolgt einen radikalen Ansatz: Standardmässig wird kein JavaScript an den Browser gesendet. Interaktive Komponenten werden als «Islands» markiert und nur dann geladen, wenn sie im Viewport sichtbar werden. Astro unterstützt dabei verschiedene Frameworks – React, Vue, Svelte – in derselben Anwendung.

HTMX

HTMX ist das konzeptionelle Gegenteil einer SPA. Statt den gesamten Zustand im Browser zu verwalten, sendet HTMX HTTP-Requests und ersetzt Teile der Seite mit dem HTML, das der Server zurückliefert. Die gesamte Logik bleibt auf dem Server. Das Frontend reduziert sich auf ein HTML-Attribut.

Gemeinsam ist diesen Ansätzen: Sie geben dem Server die Kontrolle zurück und setzen JavaScript nur dort ein, wo es tatsächlich einen Unterschied für den Nutzer macht.

Progressive Enhancement ist kein neues Konzept. Es ist ein Designprinzip, das besagt: Eine Webanwendung muss in ihrer Grundfunktion ohne JavaScript funktionieren. JavaScript wird genutzt, um die Erfahrung zu verbessern – nicht um sie zu ermöglichen.

In der Praxis bedeutet das:

Formulare funktionieren als HTML-Formulare. Sie haben ein action-Attribut, sie senden Daten per POST, sie funktionieren ohne JavaScript. JavaScript fügt Client-seitige Validierung, Inline-Fehlermeldungen und asynchronen Submit hinzu – aber wenn JavaScript nicht verfügbar ist, funktioniert das Formular trotzdem.

Navigation funktioniert als Links. Jede Seite hat eine eigene URL, die direkt aufrufbar ist. Client-Side Routing kann die Übergänge glätten, aber die Navigation hängt nicht davon ab.

Inhalte sind als HTML vorhanden. Der Server liefert die Inhalte als semantisches HTML. JavaScript kann Animationen, Lazy Loading oder interaktive Elemente hinzufügen, aber der Inhalt ist auch ohne JavaScript sichtbar und lesbar.

Die Vorteile dieses Ansatzes sind erheblich:

• Robustheit: Die Anwendung funktioniert auch bei JavaScript-Fehlern, langsamen Verbindungen oder inkompatiblen Browsern
• Accessibility: Semantisches HTML ist von Haus aus zugänglich. Ein Formular mit label-Elementen und einem submit-Button funktioniert in jedem Screenreader – ohne ARIA-Attribute
• Performance: HTML ist die schnellste Art, Inhalte an den Browser zu liefern. Kein Parsing, kein Kompilieren, kein Ausführen. Der Browser zeigt an, was er empfängt
• SEO: Suchmaschinen lesen HTML zuverlässig. Die Abhängigkeit von JavaScript-Rendering entfällt

Progressive Enhancement erfordert ein Umdenken in der Entwicklung. Statt zu fragen «Wie baue ich das in React?» lautet die Frage: «Was ist das einfachste HTML, das diese Funktion abbildet – und wo fügt JavaScript einen messbaren Mehrwert hinzu?»

Die Wahl des richtigen Ansatzes hängt vom Projektkontext ab. Ein pauschales «Framework X ist besser als Y» ist nicht zielführend. Stattdessen eine Bewertung entlang konkreter Kriterien:

Blazor SSR mit Interactive Islands

Stärken: Einheitlicher Stack in C# und .NET – Frontend und Backend in derselben Sprache, denselben Tools, derselben CI/CD-Pipeline. Starke Typsicherheit, hervorragendes Tooling und nahtlose Integration mit bestehenden .NET-Backends. Interactive Server Mode für Echtzeit-Interaktivität per SignalR.

Geeignet für: Unternehmen mit bestehendem .NET-Stack, interne Business-Anwendungen, Portale und Plattformen mit moderater Interaktivität. Teams, die nicht in zwei Technologiewelten arbeiten wollen.

HTMX

Stärken: Minimaler Overhead – eine einzige JavaScript-Datei von 14 KB. Die gesamte Logik bleibt auf dem Server, in jeder beliebigen Sprache. Geringe Lernkurve für Entwickler mit Server-Side-Erfahrung. Kein Build-System, keine Transpilation, kein Bundling.

Geeignet für: Content-lastige Websites, CRUD-Anwendungen, Prototypen und MVPs. Teams, die Komplexität minimieren wollen. Projekte, bei denen Performance und Einfachheit Vorrang vor reichhaltiger Client-Interaktivität haben.

Astro

Stärken: Island Architecture – JavaScript wird nur für interaktive Komponenten geladen, der Rest ist statisches HTML. Framework-agnostisch: React, Vue und Svelte können in derselben Anwendung koexistieren. Hervorragende Build-Time-Performance und optimale Core Web Vitals.

Geeignet für: Marketing-Websites, Dokumentationen, Blogs und Content-Plattformen. Projekte, bei denen Performance und SEO kritisch sind und Interaktivität sich auf isolierte Bereiche beschränkt.

Alle drei Ansätze teilen ein Prinzip: Der Server liefert HTML. JavaScript wird gezielt eingesetzt, nicht pauschal. Die Architekturentscheidung folgt dem Anwendungsfall, nicht dem Hype-Zyklus.

Die Kritik an SPAs bedeutet nicht, dass sie obsolet sind. Es gibt Anwendungsfälle, in denen eine vollständige Client-Side-Architektur die richtige Entscheidung bleibt:

Echtzeit-Kollaboration: Anwendungen wie Figma, Google Docs oder Miro erfordern bidirektionale Kommunikation, komplexes State Management und sofortige Reaktion auf Nutzereingaben. Server-Side Rendering kann hier die initiale Darstellung beschleunigen, aber der Kern der Anwendung lebt im Browser.

Offline-Fähigkeit: Progressive Web Apps, die auch ohne Netzwerkverbindung funktionieren müssen, brauchen Client-Side-Logik. Service Worker, lokale Datenhaltung und Background Sync setzen eine SPA-Architektur voraus.

Hochinteraktive Editoren: Code-Editoren, Bild-Editoren, Tabellenkalkulationen – Anwendungen, in denen jede Millisekunde Latenz spürbar ist und hunderte von Interaktionen pro Minute stattfinden, profitieren von Client-Side-Rendering.

Komplexe Datenvisualisierungen: Dashboards mit Echtzeit-Charts, interaktiven Filtern und Drill-Down-Navigation erfordern ein Maß an Client-Side-Logik, das sich mit Server-Rendering nicht sinnvoll abbilden lässt.

Der entscheidende Punkt: SPAs sind eine legitime Architektur für eine spezifische Klasse von Anwendungen. Der Fehler der letzten Dekade war, sie als Standardarchitektur für alle Webanwendungen zu verwenden – einschliesslich Marketing-Websites, Content-Plattformen und CRUD-Anwendungen, die von einer einfacheren Architektur mehr profitiert hätten.

Die Frontend-Landschaft normalisiert sich. Es gibt nicht mehr die eine richtige Architektur, sondern ein Spektrum von Ansätzen – vom statischen HTML über Server-Rendering mit selektiver Interaktivität bis zur vollständigen SPA. Die Aufgabe des Engineering-Teams ist, den Ansatz zu wählen, der zum Anwendungsfall passt. Bei EXPERIOR DIGITAL setzen wir auf Blazor SSR als Standard und erweitern gezielt um Client-Interaktivität, wo sie den Nutzern tatsächlich dient.