Webplattform und Laufzeitarchitektur

Webplattform und Laufzeitarchitektur

0:00 Bevor wir über Rendering-Architekturen und Frontend-Zuschnitte sprechen, lohnt ein Blick auf das Fundament: die Webplattform selbst. Das klingt nach Grundlagen, die jeder kennt — und genau darin liegt das Problem. Vieles von dem, was Teams über Browserfähigkeiten und über HTTP zu wissen glauben, stammt aus der Zeit um 2015.

0:19 Seitdem hat sich beides deutlich verändert, und zwar an Stellen, die Architekturentscheidungen betreffen. In diesem Modul aktualisieren wir dieses Bild — mit einem Maß für Browserfunktionen, das belastbarer ist als jede Faustregel.

Webplattform und Laufzeitarchitektur

0:34 Zwei Kapitel erwarten Sie. Im ersten geht es um den Browser als Anwendungsplattform und um die Frage, wie Sie belastbar entscheiden, ob Sie eine Browserfunktion einsetzen dürfen. Das zweite Kapitel widmet sich der Kommunikation: HTTP in seinen drei Versionen, die Rolle der Zustandslosigkeit und die Wahl zwischen Anfrage-Antwort und dauerhafter Verbindung.

0:54 Beide Themen wirken technisch — sind aber in Wahrheit Architekturentscheidungen mit spürbaren Folgen für Skalierung und Betrieb.

Wie eine moderne Webanwendung ausgeführt wird

1:01 Beginnen wir im Browser. Was passiert dort eigentlich, wenn Ihre Anwendung läuft — und warum ist die Antwort darauf für den Entwurf relevant und nicht nur für die Fehlersuche? Im Browser arbeiten zwei Maschinen zusammen. Die eine baut aus Ihrem Markup und Ihren Stilregeln die Darstellung auf, die andere führt Code aus. Verbunden sind sie über das Document Object Model — eine Datenstruktur, die den Zustand der Seite hält und die sich zur Laufzeit verändern lässt.

1:28 Dieses Zusammenspiel ist der Grund für fast alle Performance-Eigenheiten, die Sie im Frontend erleben: Jede Änderung am Baum kann Layout und Darstellung neu anstoßen. Wer das im Kopf hat, versteht später sofort, warum Hydration so teuer ist. Diese vier Schritte sind bewusst als Kette gezeichnet, denn die Reihenfolge ist nicht verhandelbar.

1:48 Zwischen dem Eintreffen der Antwort und dem Moment, in dem Ihre Nutzer etwas sehen, liegen drei Verarbeitungsstufen. Und jede davon kann warten — auf eine Datei, auf ein Schriftpaket, auf ein Skript. Für den Entwurf heißt das: Die Frage ist nicht nur, wie schnell Ihr Server antwortet, sondern wie viel Arbeit die Antwort im Browser noch auslöst.

2:08 Das ist die Brücke zum nächsten Modul. Vier Punkte, die zusammen ein Bild ergeben. Der Browser hat heute Zugriff auf Speicher, Netzwerk, Sensoren und sogar Hintergrundarbeit — er ist damit näher an einem Betriebssystem als an einem Dokumentenbetrachter. Besonders wichtig ist der zweite Punkt: HTML, CSS und JavaScript sind lebende Standards. Es gibt kein HTML6, auf das man warten könnte.

2:32 Funktionen kommen laufend hinzu, und genau deshalb brauchen Sie ein anderes Maß dafür, was Sie einsetzen dürfen. Darum geht es auf der nächsten Folie. Web Platform Baseline ist der Versuch, eine Frage zu beantworten, die früher jeder für sich beantwortet hat: Kann ich das schon benutzen? Statt in Browserversionen zu denken, schaut Baseline auf vier Kern-Browser — Chrome für Desktop und Android, Edge, Firefox für Desktop und Android sowie Safari für macOS und iOS.

3:01 Der Vorteil ist die Überprüfbarkeit. Die alte Einteilung in HTML5 und CSS3 beschreibt Versionen, die es so nie gab, und taugt deshalb nicht als Entscheidungsgrundlage. Baseline taugt dafür, weil es an einer gemeinsam definierten Menge von Browsern hängt. Die interessante Zahl in dieser Tabelle ist die dreißig. Dreißig Monate liegen zwischen „in allen Kern-Browsern verfügbar" und „ohne Vorbehalt einsetzbar" — das ist keine technische Größe, sondern eine Annahme darüber, wie lange Menschen ihre Geräte und Browser nicht aktualisieren.

3:32 Zweieinhalb Jahre. Das erklärt, warum die mittlere Stufe so wichtig ist: Dort ist die Funktion technisch überall da, aber noch nicht bei allen angekommen. Und das ist keine technische Frage mehr, sondern eine über Ihr Publikum. Hier liegt der eigentliche praktische Gewinn. Die Diskussion verschiebt sich von „funktioniert das?" zu „welche Stufe brauchen wir?" — und das ist eine Frage, die man gemeinsam entscheiden kann.

3:58 Für eine interne Anwendung mit verwalteter Browserflotte genügt die mittlere Stufe. Für eine öffentliche Plattform wie Kartenwerk, bei der am Einlass auch fünf Jahre alte Telefone auftauchen, sollten Sie auf der oberen Stufe bleiben. Das Entscheidende: Diese Festlegung ist überprüfbar und damit verhandelbar. Ein Bauchgefühl ist es nicht.

4:18 Der erste Punkt ist der Alltagsfehler schlechthin — es funktioniert auf dem Rechner der Entwicklerin, also gilt es als fertig. Der letzte Punkt ist der, den ich Ihnen ans Herz lege: Legen Sie im Design-System fest, welche Baseline-Stufe gilt. Eine einzige Zeile in der Dokumentation, und die Frage muss nicht mehr in jedem Ticket neu geklärt werden.

4:38 Und zum dritten Punkt: WebAssembly ist ein großartiges Werkzeug für rechenintensive Aufgaben — aber es ist selten die Antwort auf ein Problem, das eigentlich am Datenzugriff hängt.

Kommunikation im Web

4:49 Damit zur zweiten Hälfte: der Verbindung zwischen Browser und Server. Hier liegen mehr Architekturentscheidungen verborgen, als die meisten Teams vermuten — vor allem in einer Eigenschaft, die man leicht übersieht. Merken Sie sich diese Trennung, sie erspart viel Verwirrung: Die Semantik von HTTP — also Methoden, Statuscodes, Header, Caching — steht in einem eigenen Dokument und gilt für alle Versionen gleichermaßen.

5:15 Was sich zwischen HTTP/1.1, HTTP/2 und HTTP/3 unterscheidet, ist ausschließlich die Übertragung. Das ist praktisch relevant: Wenn jemand fragt, ob eine Anwendung für HTTP/3 angepasst werden muss, lautet die Antwort in aller Regel nein. Die Anwendung spricht dieselbe Sprache, nur der Transportweg darunter ist ein anderer.

5:36 Lesen Sie die Tabelle entlang der letzten Zeile — dort steckt die eigentliche Entwicklungslinie. HTTP/1.1 blockierte, weil eine Verbindung nur eine Sache auf einmal transportieren konnte; deshalb haben Browser mehrere Verbindungen parallel geöffnet. HTTP/2 löste das mit Multiplexing über eine Verbindung, verlagerte das Problem aber auf die Transportschicht: Geht ein Paket verloren, warten alle Ströme.

6:01 HTTP/3 zieht daraus die Konsequenz und tauscht TCP gegen QUIC. Der Gewinn zeigt sich deshalb genau dort, wo Pakete verloren gehen — im Mobilfunk, am Veranstaltungsabend, bei schlechtem Empfang. Diese Folie erklärt eine Eigenschaft, die so selbstverständlich wirkt, dass man ihre Tragweite übersieht. Weil jede Anfrage alles Nötige mitbringt, kann jeder Knoten jede Anfrage beantworten.

6:25 Das ist die Grundlage dafür, dass Sie beim Vorverkaufsstart einfach zehn weitere Instanzen dazustellen können. Der Preis steht im zweiten Punkt: Sitzungszustand muss irgendwo anders hin. Und der dritte Punkt ist der unterschätzte — Zwischenspeicher funktionieren nur, weil Antworten in sich vollständig sind. Zustandslosigkeit ist also keine Einschränkung, sondern die Eigenschaft, die Skalierung überhaupt möglich macht.

6:51 Diese vier Felder unterscheiden sich in zwei Dimensionen: Wer darf sprechen, und bleibt die Verbindung offen? Oben links der Regelfall, den man viel zu schnell verlässt — Anfrage und Antwort, überall zwischenspeicherbar. Server-Sent Events sind der unterschätzte Mittelweg: Der Server schiebt fortlaufend Daten, der Client hört nur zu, und es bleibt gewöhnliches HTTP.

7:12 Für Kartenwerk wäre das der passende Kanal, um während des Vorverkaufs die Zahl freier Plätze zu aktualisieren — WebSockets wären dafür schon eine Nummer zu groß. Caching ist die wirksamste Maßnahme überhaupt, und sie wird am häufigsten zu spät bedacht. Eine Antwort, die am Rand des Netzes ausgeliefert wird, erreicht Ihr System nie — sie kostet Sie nichts.

7:33 Für Kartenwerk heißt das konkret: Die Veranstaltungsseite, die beim Vorverkaufsstart zehntausendfach abgerufen wird, ist für alle gleich und gehört an den Rand. Der personalisierte Teil dagegen nicht, und das ist der letzte Punkt auf der Folie. Genau an dieser Trennlinie entscheidet sich, ob Ihre Lastspitze das Backend überhaupt erreicht.

7:53 Der zweite und der vierte Punkt hängen zusammen und sind beide teuer. Wenn der Sitzungszustand im Prozess liegt, muss jede Anfrage eines Nutzers wieder auf demselben Knoten landen — und damit haben Sie die Zustandslosigkeit aufgegeben, über die wir eben gesprochen haben. Dasselbe passiert schleichend mit WebSockets: Eine offene Verbindung bindet den Nutzer an einen Knoten, und plötzlich ist ein Rollout ohne Verbindungsabbrüche nicht mehr möglich.

8:17 Beides sind Entscheidungen, die man trifft, ohne sie zu bemerken. Im nächsten Modul geht es darum, wo Ihre Oberfläche überhaupt entstehen soll.