Welche neuen Features bringt Angular 8?

Geplant war das Release der neuen Angular-Version für Mai 2019 und tatsächlich, da ist es mit dem Release von Version 8.0.0 am 28.05.2019. Auch wenn Angular 7 noch bis April 2020 weiter unterstützt wird, macht es Sinn, sich mit der neuen Version jetzt schon vertraut zu machen.

In diesem Blog-Post werden wir uns daher anschauen, welche neuen Features bzw. Änderungen die neunte Version des Frameworks mit sich bringt. Eines dieser Features (das Ivy-Projekt) ist dabei etwas größer. Deshalb werden wir darauf zu Beginn einen genaueren Blick werfen.

Poison Ivy?! Neee… einfach nur Ivy

Das Ivy-Projekt wurde bereits auf der Google I/O in 2018 vorgestellt und befand sich damals noch in einer frühen Entwicklungsphase. Im Allgemeinen geht es bei Ivy um eine Erneuerung der Render-Pipeline, die Angular-Anwendungen für den Browser entsprechend übersetzt bzw. aufbereitet. Zur Verbesserung des Frameworks wird bei Ivy beispielsweise das Tree Shaking-Konzept angewandt, das im Folgenden kurz veranschaulicht werden soll.

Beim TreeShaking geht es unter anderem darum, nicht alle verfügbaren Funktionen beim Bauen einer Anwendung mitzunehmen. Es kommt vor, insbesondere bei dem sehr mächtigen Angular-Framework, dass manche Funktionen nicht benutzt werden. Warum sollten sie dann beim Bauen berücksichtigt werden? Wenn man an einem Apfel-Baum schüttelt, fallen schließlich auch nur die Äpfel runter, die “verwertbar” sind.

Das Aufräumen von ungenutztem Code kann dabei nun sehr gut von TreeShaking-Tools übernommen werden. Das funktioniert allerdings nur dann, wenn es eindeutig ist, dass bestimmter Code nicht benutzt wird. Schauen wir uns an, wo die Render-Pipeline von Angular durch das TreeShaking verbessert wird.

In der bisherigen Render-Pipeline von Angular wird zur Compile-Zeit ein HTML-Template in eine Datenstruktur übersetzt. Der Angular-Interpreter liest
diese Datenstruktur während der Laufzeit der Anwendung ein und baut damit ein DOM, das dem Endnutzer letztendlich im Browser angezeigt wird.


Bisherige Schritte beim Rendern von Angular-Anwendungen

Die einzelnen Schritte beim Rendern eines “Hello, world!”-Beispiels sehen dabei z. B. so aus:

1. HTML-Template als Ausgangsbasis

<pre class="wp-block-syntaxhighlighter-code"><div class="Greeting">
	Hello, world!
</div></pre>

2. Vom Angular-Compiler erzeugte Datenstruktur

viewDef(0, [
  elementDef(0, 0, null, null, 1, 'div', [['class','greet']]...),
  textDef(-1, null, ['Hello , world'!'], ...)
]);

3. Einlesen der Datenstruktur im Angular-Interpreter, um das DOM zu erzeugen

function createViewNodes(view: ViewDef) {
	view.nodes.forEach(node => {
		if (isElementDef(node)) createElement(node);
		if (hasListeners(node)) listenToElementOutputs(node);
		if (hasPipe(node)) createPipeInstance(node);
		...
	}
};

4. Resultat der Render-Pipeline im Browser

Browser-Ansicht

In der Methode des Interpreters werden im Beispiel viele der Abfragen aufgrund des minimalistischen Ausgangs-Templates negativ ausfallen.

Bisher musste der Renderer immer komplett in der kompilierten Anwendung enthalten sein, da kein Bezug zur Template-Datenstruktur hergestellt werden konnte. In unserem Beispiel könnten aber viele Teile des Renderers wegfallen. Denn ein Listener ist im Beispiel nicht vorhanden, ebenso wenig wie eine Pipe oder andere Umfänge, die beim Rendern noch abgefragt werden.

Das wird in Ivy nun vereinfacht, indem direkt aus dem HTML-Template entsprechende Befehle erzeugt werden, die das DOM für den Browser generieren. Der Zwischenschritt über die Erzeugung einer Datenstruktur durch den Angular-Compiler wird somit eliminiert. Das ermöglicht letztendlich das TreeShaking auch beim Rendern.


Render-Schritte mit Ivy

Somit werden im Nachgang nicht mehr alle Funktionen während des Bauens in das ausgelieferte Bündel an JavaScript-Dateien übernommen und der verbleibende Renderer-Code ist nur so umfangreich wie die Templates insgesamt.

Neben der TreeShaking-Strategie werden mit Ivy noch weitere Konzepte implementiert. Diese zielen insbesondere auf eine Performance-Optimierung von Angular-Anwendungen auf mobilen Endgeräten ab.

Vorstellung der Ivy-Strategien auf der Google I/O ’19

In Angular soll die Ivy-Pipeline mit Angular 8 als eine Opt-In-Möglichkeit eingeführt werden, mit der es möglich ist, zwischen der herkömmlichen Pipeline und Ivy zu wechseln. Damit einher gehen einige Vorteile, die Angular-Entwickler erwarten dürfen:

  • der Code kann vom Compiler schneller erzeugt werden
  • die Re-Build-Zeiten werden kürzer
  • die Größe von Anwendungen wird reduziert
  • umfangreiche Rückwärtskompatibilität

Ab Angular 9 soll Ivy dann auch für alle verfügbar sein, ohne über einen Opt-In-Schritt gehen zu müssen.

Bessere Performance bei modernen Browsern

Ein weiteres Feature, das neben der neuen Render-Pipeline in Angular 8 ansteht, ist das differentielle Laden von Paketen, die unterschiedliche JavaScript-Versionen enthalten. Das heißt so viel wie moderne Browser, die schon mit neueren JS-Versionen kompatibel sind, werden nicht mehr mit Polyfills belastet und können so eine bessere Performance erreichen. Polyfills-Pakete werden dann nur noch bei älteren Browsern geladen, wo sie notwendig sind, um bestimmte Features einer Anwendung zu ermöglichen.

In Angular soll es so funktionieren, dass die neue Angular CLI während des Build-Prozesses sowohl Pakete mit älteren Versionen von JavaScript (bspw. ES5) sowie modernen Versionen (ES2015+) zusammenbaut. Moderne Browser können dann die performance-optimierten, kleineren Anwendungs-Pakete, die auf ES2015+ basieren, laden.

Abhängig von der Nutzung neuer JS-Features können 7-20% der JS-Bundle Größe eingespart werden, die nicht geladen werden müssen

Verbessertes Web Worker-Bundling

Normalerweise laufen JS-Anwendungen im Browser auf einem Thread, weshalb es bei größeren Anwendungen möglicherweise zu Performance-Problemen kommen kann. Daher gibt es die Web Worker, die wie fleißige Bienen im Hintergrund der Anwendung auf separaten Threads ihre Arbeit verrichten, sodass der Nutzer davon größtenteils nichts mitbekommt. Dabei besteht allerdings das Problem, dass Web Worker-Arbeiten nicht in denselben JavaScript-Komponenten ausgeführt werden können, wie der Rest der Anwendung. Das steht wiederum im Kontrast zur Strategie der Angular CLI. Deren Ziel ist es bisher, Angular-Anwendungen in möglichst wenige JS-Dateien zu bündeln.

Genau hier greifen die Neuerungen aus Angular 8 und ermöglichen eine sauber getrennte Bündelung von Web Worker-Komponenten und der restlichen Angular-Anwendung, damit das Potenzial der Web Worker entsprechend genutzt werden kann.

Abwärtskompatibilität für den Angular Router

Die Abwärtskompatibilität des Angular Routers stellt zwar kein neues Feature für das Framework an sich dar, allerdings wird damit das Upgrade von Anwendungen, die noch auf alten Versionen des Frameworks basieren, erleichert. Mit den Änderungen in Angular 8 soll es dann möglich sein, Teile aus alten AngularJS-Anwendungen in eine neue Angular-Anwendung einzubinden.

Sharing is Caring

Für die Verbesserung des Frameworks wird es zudem in Angular 8 eine Opt-In-Möglichkeit geben, die das Teilen der Nutzungsdaten mit dem Entwicklungs-Team von Angular ermöglicht. Wie Entwickler z. B. die Angular CLI nutzen, kann zukünftig dann dabei helfen, diese weiter zu verbessern und den Entwicklern die Arbeit zu erleichtern. Die Wahrscheinlichkeit scheint dabei hoch zu sein, dass Entwickler ihre Nutzungsdaten teilen, da es sich um eine Opt-In Variante handelt und man vorab nicht dazu gedrängt wird.


Neben den oben genannten Änderungen gibt es noch einige weitere kleinere Feature, bei denen sich das Team rund um Angular in den letzten sechs Monaten, seit dem Release von Angular 7, viel Mühe gegeben hat, das Framework zu verbessern. Dazu findet ihr noch weitere Informationen im Changelog.

Lange wird es dann wohl auch nicht mehr dauern, bis das offizielle Release den Weg an die Öffentlichkeit findet. Also, fast geschafft!

Short URL for this post: https://wp.me/p4nxik-3rt
This entry was posted in Web as a Platform and tagged , , , , . Bookmark the permalink.

Leave a Reply