Angular-Renaissance Teil 1: Server-Side Rendering und Hydration
Angular 17 überarbeitet die Hydration und bietet Features wie Signale und Server-Side Rendering, wodurch Webanwendungen schneller erscheinen.
(Bild: Mirian Koridze/Shutterstock.com)
- Rainer Hahnekamp
In Angulars 17er-Reihe (17.0, 17.1, 17.2 und 17.3) haben einige neue Features Einzug gehalten, die diese dreiteilige Artikelserie vorstellt. Der erste Teil beschäftigt sich mit den Neuerungen rund um Server-Side Rendering und Hydration. Hydration steht für die nachträgliche Aktivierung von JavaScript im Browser. Der zweite Teil behandelt die Signale und welche Vorteile sie bieten, wenn sie bereits im Einsatz sind. Zu guter Letzt geht es um die neue Template-Syntax, die den Kontrollflusses verbessert und mit den Deferred Views Pionierarbeit leistet. Durch Deferred Views lassen sich anspruchsvolle Aufgaben über HTML deklarativ lösen, was in anderen Frameworks via Code geschieht.
Inmitten der Angular-Renaissance
Angular 17 gibt es seit Anfang November 2023. Mittlerweile ist die kürzlich erschienene Version 17.3 aktuell. Zwei Tage vor dem Major Release gab es ein großes Event, das die sogenannte "Angular Renaissance" offiziell einläutete und zugleich ein neues Logo präsentierte.
Startpunkt der "Renaissance" war im Grunde schon Version 14 (Release Mai 2022). Sie dauert weiterhin an, doch Angular 17 gilt schon jetzt als Meilenstein. Es kommt mit neuen nützlichen Features und ebnet – zusammen mit Version 16 – den Weg für fortgeschrittene Hydration sowie performante Signalkomponenten.
Ein Update ist möglich, ohne auch nur eines der neuen Features verwenden zu müssen. Das neueste Release Angular 17.3 läuft auch mit NgModules, ohne Signale, mit @Input/@Output, webpack und den alten Structural Directives wie *ngIf oder *ngFor. Innovation zu schaffen, ohne Breaking Changes einzuführen, ist ein Kunststück, das nur sehr wenigen Frameworks gelingt.
Wie immer bietet das Angular CLI beim Updaten mittels des Befehls ng update Unterstützung an. Eine ausführliche Anleitung zur Vorbereitung und den notwendigen manuellen Schritten ist auf der Angular-Website verfügbar.
esbuild in Angular
webpack war über viele Jahre das Tool, das Angular in seinem CLI zum Erstellen des produktiven Builds und für den Entwicklungsmodus verwendete. Damit ist nun Schluss. Seit Jahren gibt es einen Trend im Tooling-Bereich, dass neue Versionen der Tools nicht mehr in JavaScript entwickelt sind, sondern in Sprachen wie Go oder Rust, die nativen Code produzieren. Damit sind sie wesentlich schneller.
Als inoffizieller Nachfolger von webpack im Frontend-Bereich gilt Vite.js. Das Build-Tool basiert auf esbuild, das in Go geschrieben ist. esbuild ist ab Version 17 der standardmäßige Builder in Angular. Es gab in den vergangenen Releases bereits experimentellen esbuild-Support, der nun stabil ist.
Erstellt man ein neues Projekt mit Angular 17 (ng new), ist nichts weiter zu tun. In der angular.json-Datei befindet sich bereits unter builder der Eintrag @angular-devkit/build-angular:application.
Um bei einer bestehenden Anwendung in den Genuss von esbuild zu kommen, hat man die Qual der Wahl. Für die leichtgewichtige Variante ohne SSR reicht @angular-devkit/build-angular:browser-esbuild. Bis auf den Austausch des Namens sind keine weiteren Änderungen nötig.
Das volle Programm mit SSR-Unterstützung erfordert ein wenig mehr Arbeit. Der erste Schritt ist das Setzen von @angular-devkit/build-angular:application als Builder. Durch das eingebaute SSR sind weitere Parameter notwendig, die in der offiziellen Dokumentation erklärt sind.
(Bild: Rainer Hahnekamp)
Für Umstellungen von Großprojekten eignet es sich, parallel eine Angular-Anwendung auf der grünen Wiese mittels npm init @angular@17 zu erstellen und danach die neue angular.json mit der bestehenden zu vergleichen.
Für Microfrontends, die auf Module Federation aufbauen, ist der Wechsel auf esbuild mit etwas mehr Aufwand verbunden. Da Module Federation ein spezielles Feature von webpack ist, gibt es in esbuild kein Pendant. Allerdings können moderne Browser unter Zuhilfenahme von Import Maps und dem Plug-in "Native Federation für Angular" Microfrontends mittlerweile selbst stemmen. Im Hintergrund wurde nur die Technologie ausgetauscht. Die Bedienung und der Ansatz sind dieselben geblieben.
Doch lohnt sich der Wechsel auf esbuild überhaupt? Die Zahlen sprechen eine deutliche Sprache. Der esbuild-eigene Benchmark zeigt ein Vielfaches an Leistungsgewinn.
(Bild: esbuild)
Natürlich sind derartige Daten immer mit Vorsicht zu genießen. Man wird jedoch über kurz oder lang nicht darüber hinwegkommen, esbuild einzusetzen. Laut den Angular-Messungen sind bis zu 67 Prozent Geschwindigkeitsgewinn bei einem Build-Prozess ohne SSR-Prerendering zu erwarten.
Die Enterprise-JavaScript-Konferenz enterJS findet am 7. und 8. Mai in Mainz statt. Die Veranstalter dpunkt.verlag und iX präsentieren über 35 Vorträge und drei Workshops zu Themen wie JavaScript im Allgemeinen, Frameworks im Speziellen sowie Tools und Techniken rund um die Programmiersprache.
Auszug aus dem Programm:
Server-Side Rendering
Wo man auch aktuell im Frontend-Bereich hinsieht, alle Frameworks basteln emsig an serverseitigem Rendering (SSR) beziehungsweise Hydration. Ohne SSR kann es für die Endnutzerinnen und Endnutzer etwas mühsam sein, bis sie etwas von der Anwendung sehen.
Der Server schickt normalerweise ein leeres HTML mit Verweisen auf JavaScript-Dateien. Diese muss der Browser separat downloaden, parsen und ausführen. Erst durch die Ausführung läuft das Frontend-Framework und führt das eigentliche Rendering der Anwendung aus. Bei SSR führt bereits der Server das komplette Rendering durch. Der Server schickt das gerenderte HTML und CSS an den Browser und liefert die JavaScript-Dateien nach.
Der Vorteil liegt klar auf der Hand: Wenn die Seite auf dem Server bereits vorgerendert liegt, erfolgt die Auslieferung an den Browser viel schneller. Benutzer sehen somit sofort die Anwendung. Allerdings ist diese noch nicht dynamisch, da das JavaScript noch nachgeladen wird. Das Nachladen und die Integration des JavaScript-Codes in den Browser ist die sogenannte Hydration.
(Bild: Rainer Hahnekamp)
