In diesem Artikel möchte ich die Geschichte der Webentwicklung vom Beginn von HTML bis zu modernen Ansätzen wie Incremental Static Regeneration (ISR) und Partial Prerendering (PPR) erkunden. Da ich die meiste Zeit mit Next.js arbeite, nutze ich dieses Framework für Beispiele – die zugrundeliegenden Konzepte sind jedoch framework-übergreifend universell. Wer sich für die konkreten Rendering-Strategien in Next.js interessiert, findet einen vertiefenden Vergleich im Artikel Next.js Rendering Strategies.

Bevor wir in die Geschichte eintauchen, sollte klar sein, was wir meinen, wenn wir von Rendering-Strategien sprechen. Rendering ist die Umwandlung von Code in Inhalte, die Nutzer sehen und mit denen sie interagieren können. Rendering-Strategien sind verschiedene Ansätze für diese Herausforderung. Wir können die Seite zur Build-Zeit rendern, bei jedem Aufruf auf dem Server oder die Arbeit dem Client überlassen. Die Kombination dieser Ansätze und ihr gezielter Einsatz sind der Schlüssel zu einer guten User- und Developer-Experience.

HTML

Am Anfang war HTML. Entworfen 1989 als einfache Auszeichnungssprache für gemeinsame Dokumente, bot es Hyperlinks zur Navigation zwischen Dokumenten und Strukturelemente wie Überschriften, Absätze und Tabellen. 1990 gingen der erste Webserver (httpd) und der erste Browser (WorldWideWeb) online – die erste Website war geboren.

HTML war jedoch für statische Inhalte ausgelegt. Interaktivität und Personalisierung waren nicht möglich, Inhalte konnten nur durch vollständiges Neuladen der Seite aktualisiert werden.

Server-Side Rendering (SSR)

Die Lösung war serverseitiges Rendering. Statt statischer HTML-Dateien lief nun Code auf dem Server – PHP wurde als serverseitige Skriptsprache eingeführt. Datenbankabfragen ermöglichten personalisierte, dynamische HTML-Dateien zur Laufzeit.

Ein weiterer Vorteil war die bessere Developer-Experience: Generische Inhalte wie Header, Footer und Sidebars konnten zentralisiert werden. Zuvor musste bei Änderungen jede einzelne statische HTML-Datei angefasst werden.

Allerdings gab es weiterhin keine Interaktivität im Browser – das generierte HTML konnte nach dem Ausliefern nicht mehr verändert werden.

Client-Side Rendering (CSR)

1995 erschien JavaScript und ermöglichte plötzlich Animationen und Formularvalidierungen im Browser. Ein weiterer Meilenstein waren AJAX-Anfragen (Asynchronous JavaScript and XML), die es erlaubten, HTML zu aktualisieren ohne die Seite neu zu laden – eine nahtlose, reaktive Benutzererfahrung.

JavaScript brachte jedoch auch Sicherheitsrisiken wie Cross-Site Scripting (XSS), weshalb Eingabesäuberung und CORS (Cross-Origin Resource Sharing) notwendig wurden.

jQuery

2006 erschien jQuery – eine JavaScript-Bibliothek, die DOM-Manipulation und Event-Handling in kleine Funktionen abstrahierte und so repetitive Codearbeit reduzierte. Ein weiterer Vorteil war die Cross-Browser-Kompatibilität, da Browser damals unterschiedliche JavaScript-Implementierungen hatten.

Single-Page Applications (SPA)

Mit der wachsenden Leistungsfähigkeit von JavaScript kam die Idee auf: Warum die Seite überhaupt neu laden, wenn JS das HTML direkt im Browser manipulieren kann? SPAs versprachen bessere Responsivität, schnellere Ladezeiten und weniger Seitenneuladungen. Frameworks wie Backbone.js und Ember.js abstrahierten die Komplexität.

2010 brachte Google AngularJS heraus – SPAs wurden mainstream. React und Vue.js folgten mit dem Konzept des virtuellen DOM und der Komponenten-Wiederverwendbarkeit.

Doch dieser Ansatz hat auch Nachteile: Bei SPAs läuft der gesamte Code clientseitig. Das kann zu langsamen initialen Ladezeiten führen, der Browser benötigt Zugriff auf API-Credentials und die leere Seite vor dem ersten Rendern kann SEO-Probleme verursachen.

Best of Both

Kurze Zusammenfassung: Serverseitiges Rendering (PHP) brachte Dynamik, JavaScript brachte Interaktivität, SPAs verlagerten alles auf den Client.

Moderne Ansätze vereinen die Extreme von Server- und Client-seitigem Rendering, um von beiden zu profitieren. Es gibt keine Einheitslösung – moderne Webentwicklung bedeutet, die richtige Strategie für den jeweiligen Anwendungsfall zu wählen. Hybride Frameworks wie Next.js versuchen hier Klarheit zu schaffen.

Im Kern geht es immer noch um dieselben Werkzeuge wie vor 20 Jahren: JavaScript, HTML und serverseitige Skriptsprachen. Die Kunst liegt darin, sie zur richtigen Zeit am richtigen Ort einzusetzen.