Angular 17 – Eine echte Renaissance?

Gefühlt war es lange still rund um das Frontend-Framework Angular. Echte Innovationen blieben aus und man konnte das Gefühl nicht loswerden, dass Vue.js und React mit all ihren Derivaten den Vorsprung zu Angular uneinholbar weit ausbauen. Doch mit Version 17 hat das Angular-Team im Rahmen einer Keynote die Renaissance des Frameworks öffentlichkeitswirksam ausgerufen. Kein Wunder, denn der einstige Platzhirsch muss sich gegen Frameworks wie Remix oder Next.js durchsetzen. Diese haben sich stark am Markt positioniert und überzeugen durch ihre hohe Feature-Dichte sowie „Developer Experience“; und nicht zuletzt durch den Hype, der nicht selten in wellenartiger Form durch die JavaScript-Community schwappt. Mit „the next big thing“ wurde zuletzt seitens Next.js die Grenze zwischen Server- und Clientseite noch stärker verwässert. In den sozialen Medien ist von der Wiederbelebung der Skriptsprache PHP die Rede (die nie weg war und immer noch gut 75 % der Webseiten betreibt) und von SQL-Queries im Frontend. „Anarchie!“, oder „Back to the roots!“, möchte man schreien, doch soll dies nicht Thema dieses Artikels sein.

Angular hat einiges aufzuholen. Damals™, als die inhärenten Performance-Probleme von AngularJS so gravierend wurden, hat man sich bei Google dazu entschieden, das Framework von Grund auf neu zu denken und zu implementieren. Dank der starken Strukturierung mittels Konzepten wie Komponenten, Pipes, Modulen, Services, etc. sowie dem Aufsatz von TypeScript als Basis fühlte sich das Entwickeln von Webanwendungen nicht mehr „hacky“ an. Angular hatte es geschafft, dass Webanwendungen “enterprisy” wurden und gleichzeitig die „Developer Experience“ signifikant verbessert wurde.

Was damals „fancy“ und „awesome“ war, wird heute jedoch vermehrt als einengend und behäbig wahrgenommen. Viele Schritte, die bei der Implementierung von Angular-Applikationen notwendig sind, fühlen sich zu starr an und hinken im Vergleich zu React und Vue.js weit hinterher. Und vom Server-Side Rendering (SSR) wollen wir an dieser Stelle gar nicht sprechen.

Doch mit Angular 17 wird alles anders, ja, besser als es jemals war! Das Team rund um das Framework hat versprochen, wieder mehr Traktion in die Weiterentwicklung bekommen zu haben und dies in Form einer Keynote präsentiert, welche im Folgenden einmal (inklusive Einwürfen aus dem Chat) kommentiert wird.

Alles neu macht der November

Die Zeitenwende unterstreicht das Angular-Team mit dem Redesign der Marke „Angular“. Sie kommt ab sofort in peppigen Farben daher und wirkt fast wie die Corporate Identity von Adobes Creative Cloud. Das neue Corporate Design von Angular trifft den aktuellen Zeit- und Designgeist und steht somit den konkurrierenden Frameworks in nichts nach. Passend zum Redesign wurde unter der URL https://angular.dev ein komplett neu gestalteter Auftritt gelauncht, der nicht nur eine von Grund auf neu geschriebene Dokumentation mit neuen Tutorials, Essentials sowie einem Angular Playground beinhaltet, sondern auch einen Dark Mode vorweisen kann. Abgesehen davon, dass in der Vorstellung reichlich viel Aufmerksamkeit auf den Dark Mode gelegt wurde, wirkt der Auftritt leichtgewichtig und frisch. Das Team rund um Angular wirft also nicht nur mit Worthülsen um sich, sondern tischt richtig auf, bekennt sich zum Open Source-Gedanken („We love open source“) und betont den Fokus auf Performance sowie Developer Experience, was sie unter anderem in den folgenden Punkten unter Beweis stellen.

SSR & Hydration

Mit Version 17 holt Angular die Funktionalitäten rund um Server-Side Rendering sowie Hydration in die native Angular CLI, sodass kein Umweg mehr über Angular Universal Pakete mehr notwendig ist. Man hat erkannt, dass SSR mittlerweile einen wesentlichen Aspekt bei der Auswahl eines Frameworks darstellt. Mit dem Flag --ssr lassen sich nun Apps erstellen, die von Hause aus bereits Server-Side Rendering aktiviert haben, außerdem ist Hydration grundsätzlich immer mit an Board. Mit der neuen Angular Version sind SSR und Hydration als „production-ready“ ausgerufen worden. Dies ist ein überfälliger Schritt, da Next.js oder Nuxt hier bereits die Nase vorn haben. Dennoch verspricht auch hier das Team hinter Angular erneut, dass ein Hauptaugenmerk auf Performance gelegt wurde, sodass die Build-Zeit für Server-Bundles reduziert sowie der SSR-Dev-Server schneller läuft.

Neben den bereits implementierten Features wurden jedoch auch weitere Punkte genannt, an denen noch gearbeitet wird und die in folgenden Versionen zu erwarten sind. So nimmt sich das Team eine erweiterte Kompatibilität zu Nicht-Node.js-Umgebungen vor. Progressive Hydration sowie HTTP-Streaming stehen ebenso auf der Agenda wie die Verbesserung der Developer Experience rund um parametrisierte Routen.

New control flow syntax

Als Randnotiz ist die fortschreitende Integration von Signals in Angular zu vermerken. Hier wird aktuell die API „glatt gezogen“ und an der „zoneless experience“ gearbeitet. Eine totale Abkehr von Observables und Rxjs wird es jedoch so bald nicht geben. Die Empfehlung lautet weiterhin, dass für einen Stream von Events (bspw. Websockets) Observables die richtige Wahl sind und Komponent-State über Signals abgebildet werden sollte, da letztere eine feingranulare Kontrolle des States erlauben und gleichzeitig leichtgewichtiger daher kommen.

Durch Einflussnahme der Angular-Community („The star-syntax is not well understood and quirky“ oder auch „imports of NgIf and NgFor are annoying“) sowie der Umstellung auf Signals wurde die Kontrollflusssyntax umgekrempelt. Zwar funktionieren die altbekannten Direktiven ngIf oder ngFor weiterhin wie gewohnt, jedoch wird eine neue, alternative Syntax angeboten, die wesentliche Verbesserungen in Darstellung, Fehlerhandling sowie Performance umsetzt. Letzteres wird durch die Implementierung der Syntax in Angular-Core erreicht, sodass diese nicht mehr wie ngFor oder ngIf über die Angular public API funktionieren, sondern auf low-level-APIs zurückgreifen können und somit den Call-Stack erheblich reduzieren. Gerade for-loops können laut Aussage des Teams bis zu 90 % schneller sein.

ngIf wird zu @if

Neben einem else-Zweig wurde der neuen Kontrollflusssyntax auch ein else if spendiert:

<section>
    @if (user.loggedIn) {
        <app-dashboard />
    } 
    @else if(user.role === ‘admin’) {
        <app-dashboard />
        <app-admin-controls />
    } 
    @else {
        <app-login />
    }	
</section>

ngFor wird zu @for

Was bisher als best-practice bei ngFor galt, ist nun Pflicht: die Angabe von track. Allein hierüber ist es Angulars Change Detection möglich, einiges an Performance-Boost herauszuholen. Zwischen den Zeilen hört man die marketing-wirksame Zahl von 90 % Geschwindigkeitszuwachs. Jedoch wird im direkten Interview bei „control flow heavy components“ eher von 30 % schnellem Rendering gesprochen.

<section>
    @for (user of userList; track user) {
        <app-card [data]="user" />
    } 
    @empy {
        <p>There were no items in the list</p>
    }
</section>

ngSwitch wird @switch

Auch NgSwitch kann durch die neue Syntax ersetzt werden. Viel geändert hat sich hier jedoch nicht. Es gibt weiterhin kein „fall-through“, sodass ein break oder return nicht notwendig ist.

<section>
	@switch (condition) {
	   @case (caseA) {
	     <app-component-a />
	   }
	   @case (caseB) {
	     <app-component-b />
	   }
	   @default {
	     <app-component-c />
	   }
	}
</section>

Deferred loading

Deferred loading (oder auch lazy loading, aber das Angular-Team sagt „we prefer defer“) ist ein alter Hut und wird spätestens seit Version 15 unterstützt. Mit Version 17 wurde jedoch auch hier einiges neu gedacht und neu gemacht: Dank der neuen Control-Flow-Syntax ist es nun möglich, im Template einen Block mit dem Namen @defer zu definieren, der je nach übergebener Konfiguration den Inhalt nachlädt. In Kombination mit @placeholder, @loading und @error (siehe Code weiter unten) lassen sich tatsächlich gut lesbare Template-Strukturen abbilden. Jeder dieser Blöcke, so wird stets betont, läuft non-blocking. Heißt also, dass alle Komponenten, die nicht in einem @defer-Block enthalten sind, sofort gerendert werden. Spannend an dieser Stelle ist zu erwähnen, dass gerade das Thema Testing hervorgehoben wurde und man über TestBed geeignete APIs aufrufen kann, die das Abtesten der einzelnen @defer-Blöcke zulassen.

<section>
	…
	@defer (on viewport)  {
		<large-component />
	}
	<huge-component />
	<enormous-component />
	…
</section>

Custom Triggers

Lade Komponenten entweder, wenn sie in den sichtbaren Bereich gescrollt werden oder aber, wenn ein expliziter Trigger gesetzt wird. 

<section>
	<button #trigger (click)=”load=true”>
		Load Component
	</button>

	@defer (on viewport(trigger); when load == true) {
	 <large-component />
	}
</section>

Prefetch

Lade die Komponente asynchron im Hintergrund: 

<section>
	…
	@defer (prefetch on immediate; 
  prefetch when val === true)  {
		<large-component />
	}
	…
</section>

Placeholder, Loading and Error

Die Verwendung von @defer erlaubt die Kombination mit @placeholder für die Anzeige einer leichtgewichtigen Komponente, die als Platzhalter gerendert wird. @loading wiederum erlaubt das Einbinden einer Komponente,die während des Ladevorgangs gerendert wird. Sollte die in @defer eingebundene Komponente nicht ohne Fehler geladen werden, kann über @error ein Fehler angezeigt werden.

<section>
	<button #trigger>...</button>

	@defer (on interaction(trigger)) {
		<recommended-movies />
	} 
	@placeholder (minimum 500ms) {
		<img src=”placeholder.png”/>
	} 
	@loading (after 500ms; minimum 1s) {
		<spinner />
	} 
	@error {
		<p>Oops, something went wrong.</p>
	}
</section>

Easier to use: Standalone components

Das bisherige Manko einer kleineren Angular-Applikation war das Management des App Modules und das Anreichern um neue Komponenten oder Pipes. Seit Version 17 ist dies nicht mehr zwingend erforderlich, da sie Standalone by default sind. Das mag zwar auf den ersten Blick nicht gravierend erscheinen, ist aber in Kombination mit den Self-Closing Tags aus Version 16 ein echter Gewinner und hilft dabei, schöne und wartbare Komponenten zu erstellen. Mit dem nächsten Schritt, der Öffnung für Esbuild und Vite, werden weitere Konstanten des Angular-Systems (Webpack) angezählt. Nicht zuletzt durch SSR, sondern auch die generell langsame Build-Zeit wurden bereits in der vergangenen Version Vorbereitungen getroffen, Vite und Esbuild in der CLI-Build-Pipeline einzusetzen. Mit Version 17 sind diese auch nicht mehr Bestandteil der Developer Preview, sondern Standard im Toolset. Im Zuge der Umstellung erzeugt die Build-Pipeline nun ESM-Module und aktiviert die Hydration von Haus aus. Dennoch wurde auch Wert darauf gelegt, dass Webpack und somit bestehende Umgebungen weiterhin funktionieren, wobei klar kommuniziert wird, dass dies nicht mehr empfohlen wird.

Summa summarum

Angular 17 ist ein spannendes und wegweisendes Release des Frameworks, das zeigen kann und muss, ob die angekündigten Änderungen signifikanten Einfluss auf die Developer Experience haben und die Lücke zu anderen Frameworks schließen oder zumindest verkleinern kann. Sollte auch nur ansatzweise die Build-Zeit erheblich beschleunigt werden (bis zu 90 % wird vielfach genannt), ist eine wesentliche Verbesserung in Kombination mit schnellerer (testgetriebener) Entwicklung von Komponenten zu erwarten. Was durch die Keynote definitiv erreicht wurde, ist Fokus und eine Reihe von großen Versprechen in die Runde aller Webentwickelnden. Davon abgesehen wurde auch ein nicht zu vernachlässigender Hype erzeugt, der sich in Form von Diskussionen, Beiträgen, positiven wie negativen Kommentaren und weiteren Äußerungen manifestiert. Kurzum: Angular hat es geschafft, wieder von sich reden zu machen und die Roadmap für die Zukunft auszurollen.