Herzlich willkommen. Wir sind hier live von dem 4-in-1-Trainingsevent zu JavaScript, Angular, React, HTML und CSS. Und neben mir sitzt Manfred, unser Trainer heute. Hi Manfred. Schön, dass du da bist und uns ein paar Fragen beantwortest, die wir uns ausgedacht haben zu deinem Workshop aber auch so zum Thema Angular. Manfred, du bist ja Trainer, Berater und programmierender Architekt; alles mit Fokus auf Angular. Natürlich Google Developer Expert, Trusted Collaborator im Angular-Team und du sprichst auf vielen Konferenzen und Seminaren. Du gibst zum Beispiel auch das Angular Camp unter anderem, das man unter unserem Entwickler Akademie Pseudonym kennt und bringst vielen Leuten Angular bei. Gibt es denn etwas, was du noch lernen möchtest?
Ich sage immer ich bin ein wenig wie ein streunender Hund. Ich habe da keine wirklichen Pläne, keinen Masterplan für die nächsten Jahre. Sondern ich schnappe einfach immer das, was mich gerade interessiert. Das ist auch gewissermaßen eine Luxussituation, weil das funktioniert eigentlich jetzt schon so seit ich in der Arbeitswelt bin, dass ich mich halt in Sachen reinstürze die mich gerade begeistern. Und weil ich eben dann entsprechend begeistert bin, kann ich dann das Wissen auch hoffentlich gut weitergeben.
Du bist unser Angular-Experte. Welche Herausforderungen stellen sich denn Experten bei der Erstellung von wiederverwendbaren Komponenten?
Also es ist irgendwie lustig, weil man glaubt vielleicht Angular zu kennen. Aber gerade dann, wenn man wiederverwendbare Komponenten schreibt, eine Komponenten library umsetzt, ein Designsystem implementiert, dann kommt man mit ganz neuen Aspekten von Angular in Kontakt die man so vielleicht noch gar nicht so richtig gesehen hat. So Sachen, wie Händels oder strukturelle Direktiven oder wie Templates und View Container haben wir gerade besprochen. Das sind Sachen die brauche ich typischerweise nicht oder maximal aus der Blackbox-Sicht heraus, wenn ich bestehende Komponenten zu Features zusammenfüge. Aber wenn ich die Komponenten selber schreibe, einen Date Ambika oder wie gesagt mein Design System, muss ich auch in diese Untiefen vordringen. Und da muss man sich einmal hineindenken, denn das ist nicht immer unbedingt ganz simpel. Wenn man mal drinnen ist, dann macht es natürlich Sinn, aber man muss sich wirklich reindenken.
Du stellst in deinem Workshop auch weiterführende Konzepte für wiederverwendbare Komponenten vor, wie zum Beispiel Komponenten Bibliotheken. Kannst du uns noch ein anderes Beispiel nennen?
Also die Bibliotheken sind eine Möglichkeit, um Komponenten zu kapseln und wiederverwendbar zu machen. Ich kombiniere das dann auch gerne mit Werkzeugen die zum Beispiel für die Library den Changelog automatisch generieren, weil so einen Changelog zu schreiben, was hat sich geändert von Version X auf Y ist ja immer ziemlich fad und das lässt sich tatsächlich wunderschön automatisieren. Zum Beispiel indem man ein LinkedIn für die Git Commit Messages hat und dann kann man aus dem LinkedIn und anderen einen schönen Changelog, wie man ihn auch von Angular direkt kennt, ableiten. Wenn es direkt um die Komponenten geht da geht’s um so Themen wie Direktiven – Attribut Direktiven, strukturelle Direktiven, Templates, View-Container, ViewChildren, die Kommunikation zwischen Komponenten.
Spannend. Und in deinem zweiten Workshop ging es um große Angular Anwendungen und Struktur in diese zu bringen. Welche Themen hast du dort behandelt?
Also das Problem ist bei großen Anwendungen, die von vielen Entwicklern aktiv entwickelt oder gewartet werden, wo ich vielleicht sogar die Situation habe, dass ich die über Jahre hinweg weiter warten muss und wo vielleicht sogar mehrere Teams arbeiten, da muss ich irgendwie sicherstellen, dass ich links was ändern kann, ohne rechts was kaputt zu machen. Und um das Ziel zu erreichen haben wir uns unter anderem mit Domain Driven Design beschäftigt. Das bietet mal Lösungen auf der logischen Ebene. Die Lösungen haben wir übertragen auf ein NX Monorepo, also ein großes Quellcode Repository, dass aus kleinen Fragmenten besteht die gemeinsam eben das gesamte System ergeben. Das heißt mit dem Monorepo kann ich eine große Lösung in kleine Häppchen untergliedern, kann dann sogar bei NX festlegen welches Häppchen auf welches andere Häppchen Zugriff hat. Somit vermeidet man, dass jeder mit jedem kommuniziert und dass ich links was ändere und damit rechts etwas kaputt mache, obwohl das gar nicht beabsichtigt ist. Dieses „Verschlimmbessern“, wie manche Leute auch sagen. Basierend auf dem haben wir uns dann mit Micro-Frontends beschäftigt. Micro-Frontends sind die eigentlich ja nichts anderes wie die Idee von Domain Driven Design auf die nächste Ebene gebracht. Plötzlich hat man pro Untergliederung eine eigene Anwendung. Somit können verschiedene Teams möglichst autonom arbeiten. Jedes Team hat seine Anwendung oder Anwendungen und kann autonomen dran arbeiten. Wenn sie fertig sind, dann werden die deployed. Also die Teams müssen sich weniger untereinander abstimmen, was immer dann super ist, wenn man merkt bei meinen vielen Teams wird der Abstimmungsaufwand einfach zu groß. Somit bekomme ich dann die Agilität von kleinen Teams zurück, obwohl ich große Lösungen schreibe.
Klingt gut, nach einem sehr spannendem Thema. Du hast gerade schon viel erklärt, wann Micro Frontends Sinn machen. Wann machen Sie denn nicht Sinn?
Also ich würde sagen nicht Sinn machen sie, wenn ich nur ein Team habe oder wenn ich vielleicht eine kleine Anzahl an Teams habe, die eigentlich auch über ein Monorepo zusammenarbeiten könnten. Ist das nicht der Fall, habe ich mehrere Teams und vertragen sich die nicht in einem einzigen Monorepo, weil die einen anderen Hintergrund haben, weil die Experten für unterschiedliche Domänen sind, weil die vielleicht ganz woanders sitzen, dann sind Micro Frontends sehr charmant. Dann kann das Team eben autark arbeiten, sogar eigene Entscheidungen treffen – Architekturentscheidungen aber auch Technologieentscheidungen. Das heißt schlussendlich könnte ich sogar in einer Micro-Frontend Architektur mehrere Frameworks haben. Mache ich nicht aus Jux und Tollerei. Aber es macht langfristig Sinn weil wir alle wissen, Technologien kommen und gehen; Nach ich würde mal sagen sieben Jahren muss sich eine Technologie entweder drastisch neu erfinden oder sie ist weg vom Fenstern und aus dem Grund tut schon gut wenn ich nach sieben Jahren mal das nächste Modul, die nächste Domäne mit einer aktuelleren Technologie programmieren kann. Somit kann man vom Text wegmigrieren zu einer Moderneren hin. Also Sinn macht es vor allem dann, um auf die Frage noch einmal zurückzukommen, wenn ich mehrere Teams habe, und als Nebeneffekt bekommt man, dass man peu à peu den Technologiestack migrieren kann.
Stay tuned
Bei neuen Artikel & Eventupdates informiert werden:
Ok. Und dann habe ich jetzt noch eine letzte Frage an dich. Ich hatte vorhin schon erwähnt, du bist Trusted Collaborator im Angular-Team. Du hast also exklusive Einblicke. Kannst du uns sagen, ob es dann irgendwelche Neuerungen gibt, die demnächst auf uns zukommen in der Angular Welt?
Also was man derzeit auch sieht – da braucht man gar nicht exklusive Einblicke – das Angular Team arbeitet an zwei großen Themen derzeit. Das eine Thema ist Signale und das andere Thema ist Hydration. Bei Signalen/Signals geht es um einen neuen reaktiven Building Blog – so ähnlich wie ein RX-Chairs, aber viel einfacher – und weil das eine reaktive Bildung ist kann mir dieser Building Blog Bescheid geben wenn sich gebundene Daten ändern. Also ich habe vielleicht eine Adresse, die stelle ich dar im Browser und plötzlich ändert sich die Adresse, weil ich umgezogen bin und jetzt könnte das Signal Angular sagen: Pass auf, da hat sich was geändert und deswegen weiß Angular, es muss jetzt genau den Teil der Adresse aktualisieren. Also ich kann die Aktualisierung im Browser viel zielgerichteter machen. In der Vergangenheit sind immer ganze Komponenten aktualisiert worden und in der Vergangenheit war auch RX-Chairs nicht für jeden unbedingt immer simpel. Mit Signalen ändert sich beides. Es ist reaktiv, aber simpel und sehr zielgerichtet und nebenbei bekomme ich damit auch Altlasten Weg wie zum Beispiel Zone Chairs. Das ist von Anfang an bei Angular dabei und irgendwie so an der Grenze zwischen genial und ein wenig speziell und das kriegt man damit auch raus. Also Signale ist das eine. Das andere ist Hydration. Hydration ist eher interessant, wenn ich öffentliche Website schreibe, wo es um die Start Performance geht. Bei öffentlichen Websites muss relativ schnell was zum Schauen da sein, ansonsten springen die Benutzer ab. Da gibt es sehr schöne Statistiken wie sich der Umsatz nach unten entwickelt, wenn sich die Ladezeiten nach oben entwickeln – gerade bei anonymen Benutzern. Mit Hydration schafft man es, dass man zuerst serverseitig vorrendert. Das heißt ich liefere eine Seite aus und sehe sofort was – sehe sofort den Inhalt. Die Seite ist allerdings noch nicht interaktiv, weil sie erstmal statisch ist. Aus dem Grund lädt dann Angular peu à peu einzelne Komponenten nach damit die zum Leben erweckt werden. Das klappt prinzipiell schon länger. Das Stichwort war das Server-Side Rendering. Das Problem beim klassischen Server-Side Rendering war, ich habe auf einmal den gesamten Programmcode heruntergeladen. Das heißt ich habe ganz lange warten müssen, bis meine Seite, die ich schon gesehen habe, wirklich interaktiv war. Und das ändert sich jetzt mit Hydration, mit Progressive und Partial Hydration. Progressive Hydration bedeutet, das Ding überlegt sich welche Teile in welcher Reihenfolge heruntergeladen und mit Leben erfüllt werden. Vielleicht gibt es ein paar die ganz wichtig sind – der „Kaufen“ Button – und vielleicht gibt es ein paar Teile, die zwar auch wichtig sind, aber dennoch nachrangig sind. Bei einem Shop ist das vielleicht der Produktvorschlag – was könnte ich mir sonst noch kaufen. Da kann es dann eine Priorisierung geben und somit habe ich das Beste aus beiden Welten. Ich sehe relativ schnell was und die wichtigen Teile werden auch sehr schnell interaktiv, weil die zuerst geladen werden und nicht alles gemeinsam geladen wird. Das wäre progressive Hydration. Also nach und nach die Teile mit Leben erfüllen. Vielleicht gibt es dann irgendwann basierend darauf auch sowas wie Partial Hydration, wo sich ein Mechanismus überlegt was ich eigentlich gar nicht benötige. Wenn ich statischen Text habe den muss ich nicht zum Leben erwecken und Teile, die ich nie in den sichtbaren Bereich scrolle, muss ich auch nicht zum Leben erwecken. Die könnte man weglassen oder man könnte das rauszögern bis eben gescrollt wird. Und da arbeitet das Angular Team eben gerade fleißig dran und auch diesen Use Case abzudecken. Übrigens beide sind Use Cases, die derzeit auch von anderen Frameworks verfolgt werden. Da sieht man Angular ist bemüht am Puls der Zeit zu bleiben und diese ganzen Trends auch aufzunehmen.
Danke für das Interview und für die Beantwortung. Du bist bestimmt nächstes Jahr auch wieder mit dabei bzw. schon dieses Jahr im Oktober in Berlin. Also gerne vorbeikommen – Manfred ist auch da.
