Julia Martin: Angular 6 hat nochmal einiges für Angular-Entwickler verändert. Welche Features dieses Releases waren für dich am wichtigsten?
Roman Roelofsen: Interessant ist, dass sich bei diesem Release gar nicht so viel an dem API verändert hat, sondern vor allem drumherum. An erster Stelle fällt mir Schematics ein; das ist im Grunde eine Erweiterung des Build-Systems, des Toolings drumherum. Gängigen Schritten, die in der Projektentwicklung anfallen, wird ein Gerüst beziehungsweise ein Rahmenwerk gegeben, auf das aufgebaut werden kann. Ein Beispiel, das jeder kennt, ist das Material Design von Google. Es gibt eine Bibliothek für Angular, um Material Design zu nutzen. Wenn ich das bisher nutzen wollte, musste ich die readme lesen, Abhängigkeiten hinzufügen und ein „Hello World“ einbauen. Ich musste also schon anfangen zu programmieren, obwohl ich noch gar nichts gemacht habe. Mit den Schematics wäre das eine Zeile Code und ich hätte ein fertiges Gerüst. Dadurch, dass dieses Gerüst standardisiert ist, können verschiedene Schematics aufeinander aufbauen. Die Hoffnung ist, dass so ein gewisses Ökosystem von verschiedenen Lösungen entsteht, um das sogenannte Scaffolding, also typische Aufgaben im Projektstart zu automatisieren.
Julia Martin: Der Ivy Renderer war ja in Angular 6 als Betaversion implementiert und kommt mit Angular 7 als fertiges Feature dazu. Was ändert sich nun?
Roman Roelofsen: Zunächst hoffen wir mal, dass das mit Angular 7 rauskommt – ich bin da noch nicht so überzeugt. Aber das ist nicht schlimm. Es ist eine riesige Veränderung, die da vorgenommen wird.
Im Grunde ergeben sich dadurch drei Vorteile: Der erste ist das übliche „Jetzt ist alles schneller“. Wenn ich etwas programmiere oder in den Dateien verändere und diese Änderungen dann im Browser sehen will, geht das jetzt schneller. Das ist ja ganz nett, aber erstmal nicht besonders sexy. Die anderen zwei Dinge sind jedoch sehr interessant: Ein Vorteil von Angular ist, dass die UI deklarativ geschrieben wird. Das heißt, ich schreibe HTML. Deklarative Sprachen haben den Vorteil, dass sie sehr semantisch sind, man sich nicht damit beschäftigen muss, wie sie funktionieren, und dass sie sehr domänenspezifisch sind. SQL wäre dafür ein Beispiel. Der Nachteil von deklarativen Sprachen ist aber, dass sie beim Debuggen sehr schwierig sind; das beißt sich. Debugging ist immer imperativ. „Ich gehe schrittweise vor“ ist imperativ; deklarativ kennt dieses Konzept nicht. Mit dem Ivy Renderer werde ich demnächst in der Lage sein, in meinen Templates im HTML Breakpoints zu setzen. Ein klassisches Beispiel: Wenn NgIf triggert, kann ich einen Breakpoint setzen und im Browser springt er in die HTML-Datei. Dann werden die Source Maps genutzt – das Feature, das auch schon lange für TypeScript benutzt wird. Die dritte Kategorie ist die sicherlich am meisten kommunizierte und auch interessanteste. Einer der Nachteile und Kritikpunkte von Angular war immer, dass Angular relativ groß ist. Wenn ich also etwas ausliefere, beispielsweise 300 KB, enstehen dadurch Fixkosten. Das ist vielleicht ein bisschen zu viel, aber es war auf jeden Fall relativ viel im Vergleich zu anderen Frameworks. Mit dem Ivy Renderer wird die Art, wie meine Templatedateien bzw. die HTML-Dateien zur Laufzeit verwertet werden, komplett umgestellt. Es war schon immer so, dass das auf meinen von Angular kompilierten HTML-Dateien basierende Ergebnis zur Laufzeit verarbeitet wurde. Früher war das eine Datenstruktur, in der stand, welche Difs, welche Spans und welche Inputelemente ich habe. Zur Laufzeit ist Angular dann hingegangen und hat geschaut: „Ok, was ist in dieser Datenstruktur? Dann stelle ich was dar.“
Der Nachteil daran ist, dass ein Konzept namens Treeshaking nicht besonders gut funktioniert. Treeshaking heißt, dass man die Anwendung schüttelt und alles, was nicht benutzt wird, also alle losen Blätter, herunterfallen. Das Ergebnis davon ist, dass der Baum nachher schlanker wird. Das kann ich aber nicht machen, wenn der Übergang von Datenstruktur zu Angular so funktioniert. Angular weiß nicht, was potenziell in den Datenstrukturen vorliegen wird. Daher muss vor der Laufzeit erstmal alles da sein.
Im Ivy Renderer ändert sich das jetzt. Der Compiler für die Templatedateien erzeugt nicht mehr diese Datenstruktur, sondern direkt die Anweisungen, die nachher das HTML erzeugen. Jetzt funktioniert auch das Treeshaking wieder und es kann geschaut werden, welche Anwendungen überhaupt vorhanden sind. Die nicht vorhandenen bzw. nicht benutzten fallen beim Treeshaking herunter. Es gibt schon ein paar interessante Statistiken, die natürlich auch immer schön aufbereitet sind. Das schlimmste Beispiel wird da mit dem besten verglichen. Zuletzt wird jedoch das Hello-World-Beispiel genutzt: einfach nur einen String darstellen und keine anderen Features von Angular nutzen. Bisher lag das Ergebnis bei ungefähr 30 KB oder ein bisschen größer. Mit dem Ivy Renderer sind es 2,7. Also unter 10 Prozent Verbesserung. Das hat natürlich enorme Auswirkungen zur Laufzeit. Auch ganz wichtig: Für den Programmierer ändert sich gar nichts. Es ist eine komplett transparente Veränderung; man muss nichts anders programmieren und gar nicht wissen, dass es passiert. Auf einmal ist einfach nur die Dateigröße deutlich kleiner.
Julia Martin: Was tut sich darüber hinaus noch bei Angular? Version 7 ist ja fast da, Version 8 steht in den Startlöchern. Welche neuen Features wird es da geben?
Roman Roelofsen: Wie ich meinte: Ich glaube nicht, dass Ivy in Version 7 fertig vorhanden sein wird. Das heißt, damit wird es weitergehen; 8 ist dafür hoffentlich ein realistisches Ziel. Also nach 7 weitere Betaversionen für Ivy – vielleicht dann über ein Flag auch aktivierbar – sodass man mal für sich testen kann. Außerdem eine ganz neue Schublade: Basel. Das ist ein Build-System, das auch von Google kommt, dort auch intern verwendet wird und im Grunde webpack austauscht, das derzeit verwendet wird. Das ist auch transparent für den Benutzer. Viele Programmierer werden webpack kennen, aber wenn ich Angular entwickle, habe ich damit erstmal keine Berührungspunkte. Das bedeutet auch, dass der Wechsel transparent ist und das Ziel auch hier das bekannte „schneller, runder, besser“ ist. Das wird sicherlich ein wesentlicher Bestandteil sein. Das dritte Feature finde ich am interessantesten; das ist wieder die Kategorie „sexy“, auch wenn sie nicht so viel kommuniziert wird. Das Feature heißt „Feature“. Das macht es ganz angenehm, darüber zu reden. Man könnte es auch anders nennen: Higher-order Components. Bisher war die Schnittstelle zwischen Angular und den Komponenten, die ich schreibe, eine Blackbox – da konnte man nicht dran. Mit dem Feature „Feature“, den Higher-order Components, kann ich da eingreifen. Das öffnet ganz neue Möglichkeiten von Metaprogrammierung. An Dev-Tools kann ich mir viele Dinge vorstellen, aber auch zur Laufzeit ganz neue Arten bzw. Bibliotheken, die mir bei der Angular-Entwicklung helfen. Das hängt natürlich im Endeffekt davon ab, wie und wofür es genutzt wird oder ob es dafür Bibliotheken gibt. Das Potenzial ist jedoch enorm.
Julia Martin: Häufige Releases bedeuten auch häufiges Migrieren, um auf dem aktuellen Stand zu bleiben. Wie viel Aufwand ist das bei den aktuellen Versionen?
Roman Roelofsen: Die Frage ist bei Angular leider immer berechtigt. Von Version 1 zu Version 2 hat sich alles verändert. Das war ein Big Bang und eigentlich der schlimmste anzunehmende Migrationsaufwand. Seitdem ist es eigentlich immer trivial gewesen. Die Veränderungen, die es gab, waren überschaubar. Hier und da mal eine API-Verwendung anzupassen ist kein Problem. Entscheidend ist, dass sich an der Semantik nichts mehr verändert hat und derzeit auch nichts auf dem Radar ist, was sich verändern würde. Diese Dinge würden Chaos bedeuten, sind aber nicht absehbar. Das heißt, in den letzten Versionen war das eigentlich nie ein Problem und ich bin bei der Migration auch nicht einmal auf Probleme gestoßen.
Julia Martin: Wie ist das mit den Leuten, die noch immer mit der ersten Version, also mit Angular JS arbeiten – hast du da einen Tipp, wie die Migration gelingen kann?
Roman Roelofsen: Gerade weil der Wechsel von 1 auf 2 so groß war, gab es von vornherein Tools von Google, um bei der Migration zu helfen; ng update war das Schlagwort. Da geht es im Grunde darum, dass ich eine Angular-1-Anwendung in Angular 2 laufen lassen kann oder auch Angular-2-Komponenten downgraden kann, sodass sie in Angular 1 funktionieren. Das klingt erstmal gut und für einen Blogartikel ganz toll. Aber in der Praxiswurde immer der gleiche Fehler gemacht, wann immer ich gefragt wurde und Teams bei der Migration helfen durfte. Man hat, weil es diese Möglichkeit gab, versucht, die Migration in kleinen Schritten zu machen und diese Schritte im Projektverlauf zu vergrößern. Man sagt: „Ich fang mal an und migriere nur diese kleine Komponente, mache ein Downgrade von einer neuen und irgendwann ist hoffentlich alles migriert.“ Das fliegt einem aber um die Ohren. Man hat auf dem Weg dahin eine Codebasis, mit der man nicht arbeiten möchte, die nicht skaliert – das macht keinen Spaß. Meine ganz klare Empfehlung wäre, anfangs einen gewissen größeren Schritt zu gehen und dann kleinere. Das würde konkret bedeuten: neues Projekt-set-up mit Angular in einer aktuellen Version, komplett Angular-CLI-basierend; die Routings umstellen, sodass die Navigation über Angular geschieht, und dann schaut man innerhalb der Seiten, innerhalb der Dialoge, welche Komponente von Angular 1 man nachträglich wieder reinziehen kann, damit es nicht neu gemacht werden muss.
Julia Martin: Angular, React und Vue – es gibt ja viele Frameworks. Wie schätzt du die Entwicklung im JavaScript-Ökosystem ein? Wo liegen die Trends?
Roman Roelofsen: Momentan sehe ich da zwei Ströme. Der erste ist der, dass in den letzten Jahren die JavaScript-Frameworks auch in ihrer Featuremodalität in ihrer Größe explodiert sind. Es ist enorm, was mittlerweile geht und das ist toll. Dabei haben wir vergessen, dass wir in unserer westlichen Welt tolle Handys und Datenverbindungen haben. Was wir jedoch an Daten über das Internet verschicken, ist eine Menge, die selten in einem Verhältnis zu dem steht, was die Anwendung im Endeffekt tut. Dabei geht also der erste Trend, den ich sehe, in Richtung Microframeworks. Das gleiche haben wir auch auf dem Server gesehen. Man ist weg vom Monolithen gegangen und baut vermehrt kleinere Pakete; idealerweise hilft das Framework dabei. Es bringt nichts, ein kleines schönes Paket zu schnüren, wenn das Framework an sich wieder ein Monster ist. Entsprechend sprudeln im Moment ein paar Web- und Microframeworks, die versuchen, das zu bedienen.
Da hilft Angular glücklicherweise wieder der Ivy Renderer, der das Ganze herunterskaliert, sodass ich quasi mein Angular mit den Features bekomme, die ich nutze – dann ist das mein Micro-Angular. Der zweite Trend knüpft dort an; das sind die Web-Components. Was alle diese Frameworks – Angular, React und Co. – gefühlt gemacht haben war, das DOM API zu erweitern, sodass ich neue Elemente bekomme, um meine UI zu beschreiben. Das Problem ist, dass es immer Silos, also Kontinente, waren. Man konnte also nicht dazwischen wechseln. Eine Komponente in React konnte man nicht in Angular verwenden, das hätte man komplett neu schreiben müssen. Das ist eigentlich schade, denn so hat das Web nicht funktioniert. Das Web war immer eine offene Umgebung, wo von verschiedenen Parteien Dinge gleichzeitig benutzt werden konnten. Die Web-Components standardisieren über alle Browser hinweg diesen Mechanismus, sodass ich eigene Elemente definieren kann. Das würde bedeuten, ich kann einen Calendar Datepicker in Angular schreiben und den in React nutzen. Auch hier zeigt sich: Das ergibt keinen Sinn, wenn mein Framework dann wieder einen Megabyte groß ist. Deshalb diese Microframeworks, da will ich natürlich nicht mehr ausliefern als ich muss. So in diese Richtung wird es weiter gehen. PWA ist noch so ein Thema, aber mal schauen wie relevant, dass sich das in die Frameworks durchzieht oder ob einfach die Frameworks sagen „Wir haben jetzt PWA-Support.“
Julia Martin: Zum Abschluss würde ich gerne noch deine persönliche Meinung hören: Warum sollte man jetzt Angular benutzen und nicht React oder Vue.js?
Roman Roelofsen: Das wird man noch oft gefragt. Meine erste Antwort ist immer: Wenn ich ein Projekt mit Framework A versemmel, dann hätte ich es auch mit B und C versemmelt. Man sollte dann nicht erwarten, dass das eine zum Projekterfolg führt, wenn es das andere nicht getan hat. Am Ende ist es eine persönliche Präferenz; meine fällt auf Angular und der Grund ist relativ simpel beziehungsweise im Vergleich konkurrenzlos. Es reicht nicht mehr zu sagen: Ich habe eine Webanwendung geschrieben, die ein Formular hat, in das ich etwas eingeben kann. Wir wollen Animationen haben, wir brauchen Initialisierung, wir brauchen kleine Dateien, die wir ausliefern können und so weiter. Testbarkeit ist ebenfalls wichtig. Angular ist von diesen Alternativen das einzige Framework, das diese Dinge bereits extrem gesamtheitlich betrachtet. Der Ivy Renderer war dafür wieder ein Beispiel: Wenn man sich die Changelogs anschaut, tauchen regelmäßig Veränderungen am Ivy Renderer auf, die speziell für Animationen gemacht sind. Da sieht man, dass die Dinge nicht isoliert, sondern gesamtheitlich betrachtet werden. Das führt zu einem System, in dem ich alles finde, was ich brauche. Zurück zum Ivy Renderer: Wenn nur noch das übrig bleibt, was ich tatsächlich benutze, habe ich natürlich eine Traumumgebung. Das andere sind dann größere Projekte, wo die Projektmitglieder wechseln. Ich hatte noch nie so sehr diesen Effekt wie bei Angular, dass ich in ein Projekt reingehen konnte und die Struktur sofort verstanden habe, in der Lage war, alles zu erweitern, Bugs zu fixen, neue Features hinzuzufügen – das geht natürlich nur, wenn eine Struktur vorgegeben wurde. Das heißt auch, dass ich die Struktur nicht immer mag, aber das ist die Konsequenz, wenn sich zehn Leute auf eine Struktur einigen – es wird immer welche geben, die die konkret gewählte nicht so gut finden – aber Hauptsache, man hat eine. Da ist Angular für mich ungeschlagen und deshalb würde ich die Wahl immer wieder treffen.
Julia Martin: Das sind schöne abschließende Worte. Vielen Dank, Roman, dass du heute bei uns warst.
