Manfred Steyer, Google Developer Expert für Angular, gibt spannende Einblicke in die neuen Features von Angular 20 – von Signals über dynamische Komponenten bis hin zu KI-Integration. Im Gespräch beleuchtet er die Zukunft des Frameworks, seine Stärken und die Herausforderungen, denen sich Entwickler:innen stellen müssen.
Ines Chargui: Hallo Manfred! Kannst du zu Beginn einmal Angulars Grundphilosophie erklären? Wie unterscheidet sich Angular von anderen Frontend-Frameworks wie React oder Vue?
Manfred Steyer: Ich denke, dass man heutzutage technisch gesehen mit allen gängigen Frameworks nahezu alles umsetzen kann, da sie sich stark ähneln. Allerdings hatte ich immer den Eindruck, dass Angular auch nicht-technische Vorteile bietet. Zum Beispiel wird es von Google selbst entwickelt und verwendet, was für langfristige Stabilität spricht. In einem heutigen Ökosystem, in dem viele Open-Source-Frameworks kommen und gehen, schafft diese Rückendeckung Vertrauen – denn man kann davon ausgehen, dass das eingesetzte Tool Bestand haben wird und nicht so bald vom Markt verschwindet.
Ein weiterer Aspekt, in dem Angular glänzt, ist die Vielzahl an Funktionen, die man direkt „out of the box“ erhält. Neben Komponenten stehen auch Dependency Injection, Testing, HTTP-Zugriff, Reaktivität, Routing, Formulare und vieles mehr zur Verfügung. Dabei ist alles optimal aufeinander abgestimmt, was den Aufwand erspart, verschiedene Bibliotheken manuell zusammenzustellen. Zudem sorgt dieser ganzheitliche Ansatz für ein konsistentes und nahtloses Entwicklererlebnis – denn alles kommt aus einer Hand.
Ines Chargui: Jetzt, wo wir über die Vorteile von Angular gesprochen haben – welche Nachteile gibt es, und warum könnten sich Entwickler:innen stattdessen für andere Frameworks entscheiden?
Manfred Steyer: Eine Beobachtung aus der Vergangenheit ist, dass Angular besonders gut für Anwendungen im Unternehmensmaßstab geeignet ist. Für sehr schlanke Anwendungen – etwa eine kleine CMS-Integration in WordPress – kann Angular jedoch überdimensioniert wirken. In solchen Fällen greifen viele Unternehmen lieber zu React oder Vue.
Das Angular-Team ist sich dieser Herausforderung bewusst und arbeitet aktiv daran, überflüssigen Ballast abzubauen, um das Framework auch für einfachere Anwendungsfälle attraktiver zu machen. So sind Module mittlerweile optional und werden in neuem Code in der Regel nicht mehr verwendet, was die Codebasis vereinfacht. Auch das neue, leichtgewichtige Reaktivitätssystem reduziert unnötige Komplexität. Mit diesen Verbesserungen fühlt sich Angular inzwischen genauso schlank und flexibel an wie andere moderne Frameworks.
Ines Chargui: Signals hat in letzter Zeit viel Aufmerksamkeit bekommen. Kannst du erklären, was genau dahintersteckt und warum es aktuell so stark im Fokus steht?
Manfred Steyer: Die Idee hinter Signals ist es, einen einfachen reaktiven Baustein bereitzustellen, der einen veränderbaren Wert hält. Dieser Wert kann aktualisiert und beobachtet werden – das heißt, Änderungen am Wert können erkannt und darauf reagiert werden.
In erster Linie nutzt Angular selbst diese Reaktivität: Das Framework muss wissen, wann sich etwas ändert, um ein erneutes Rendering auszulösen und die Ansicht sowie die betroffenen Komponenten zu aktualisieren.
Doch auch die Anwendung selbst kann davon profitieren – etwa indem sie bei jeder Wertänderung automatisch neue Berechnungen durchführt. Beide Anwendungsfälle bringen klare Vorteile mit sich.
Die Fähigkeit von Angular, präzise zu erkennen, wann und wo sich Daten ändern, erhöht die Effizienz der Anwendung – denn so werden umfassende Dirty-Checks über die gesamte Komponente oder Anwendung hinweg vermieden. Dadurch lässt sich die Änderungserkennung gezielt optimieren.
Ein gutes Beispiel dafür ist die einfache Umstellung auf die OnPush-Strategie.
Man kann sich das vorstellen wie bei einer Excel-Tabelle: Wenn sich ein Zellwert ändert, werden alle davon abhängigen Zellen automatisch neu berechnet. Man muss keine manuelle Logik mehr pflegen wie ‚Wenn sich dieser Wert ändert, dann aktualisiere auch jenen‘. Alles bleibt automatisch synchron.
Das sind die beiden größten Vorteile. Manche würden einwenden, dass das nichts grundlegend Neues sei, da RxJS und Observables bereits seit Langem ähnliche Möglichkeiten bieten – und das stimmt: Alles, was sich derzeit mit Signals umsetzen lässt, ist grundsätzlich auch mit RxJS machbar.
Der entscheidende Vorteil von Signals liegt jedoch in ihrer Einfachheit. Sie erleichtern die Umsetzung häufiger Anwendungsfälle und sind besonders zugänglich für Entwickler:innen, die neu in Angular oder in reaktive Programmierung einsteigen.
Zwar sind Signals nicht so mächtig oder flexibel wie Observables, dafür aber deutlich leichter zu verstehen und anzuwenden. Für komplexere Anforderungen steht RxJS selbstverständlich weiterhin zur Verfügung.
Ines Chargui: Was hat dich ursprünglich zu Angular hingezogen? Wie hat deine Angular-Reise begonnen?
Manfred Steyer: Ich glaube, es war irgendwann zwischen 2010 und 2012, als mir bewusst wurde, wie wertvoll es ist, viele Funktionen direkt ‚out of the box‘ zu erhalten. Damals bestand die Arbeit im JavaScript-Ökosystem oft darin, verschiedenste Tools und Technologien miteinander zu kombinieren.
Ich nutzte Knockout.js für die Datenbindung, einige jQuery-Bibliotheken für die Benutzeroberfläche und ein komplett separates Toolset für das Testen – doch nichts davon fühlte sich wirklich stimmig an.
Schließlich wechselte ich zu AngularJS. Auch wenn es sich dabei noch um ein ganz anderes Framework als das heutige Angular handelte, begann ich früh, Angular 2 zu erkunden – noch während der Alpha- und Beta-Phase. Etwa zur gleichen Zeit begann ich auch, Unternehmen bei der Einführung von Angular 2 zu beraten.
Ines Chargui: Wie würdest du die Entwicklung von Angular beschreiben? Nach allen Stadien, die das Framework durchlaufen hat, ist es noch auf dem richtigen Weg?
Manfred Steyer: Ich glaube, Angular ist wirklich auf dem richtigen Weg. Das Angular-Team hat immer wieder gezeigt, dass sich die zugrunde liegende Philosophie und die gesamte Architektur auszahlen. Dadurch kann sich Angular im Hintergrund kontinuierlich neu erfinden. Wir sehen nicht viele dieser Neuerungen direkt, aber Angular schafft es, mit all den Innovationen da draußen Schritt zu halten, zumindest mit denen, die für Single-Page-Anwendungen oder Webanwendungen im Allgemeinen relevant sind.
Nur ein Beispiel: Vor einigen Jahren wurde die gesamte Rendering-Engine durch die neue Ivy-Engine ersetzt. Das geschah größtenteils im Hintergrund, ohne größere Breaking Changes, sodass wir effektiv ein modernisiertes Framework ohne die üblichen Migrationsschmerzen erhielten. Jetzt macht Angular das erneut. NgModules sind optional, Zonen werden optional, und mit Signals erhalten wir einen neuen Satz Reaktivitätsprimitive. All das funktioniert ohne Breaking Changes. Bestehender Code läuft weiterhin, was besonders in Unternehmensumgebungen wichtig ist, in denen Anwendungen über Jahre oder sogar Jahrzehnte gepflegt werden sollen.
Neuerfindung ohne Unterbrechung ist Angulars Motto, bisher hat das Framework bewiesen, dass es dieses Versprechen einlösen kann.
Ines Chargui: Gibt es mit der Veröffentlichung von Angular 20 Features, die du besonders spannend findest?
Manfred Steyer: Die Signal-Story hat sich weiterentwickelt. Viele zentrale Bausteine – etwa Effekte oder die Interoperabilität mit RxJS – erreichen inzwischen einen stabilen Status. Die neue Resource-API, mit der sich Daten im reaktiven, signalbasierten Flow abrufen lassen, wird bald in die Developer Preview überführt.
Gleiches gilt für weitere zentrale Neuerungen wie Incremental Hydration, Hybrid Routing und die zone-less Change Detection.
Ines Chargui: Hast du mit diesen Neuerungen bereits selbst experimentiert?
Manfred Steyer: Ja, absolut. Ich war ein früher Nutzer der Reaktivitätsfeatures wie der Resource-API und der verknüpften Signals. Für mich waren sie immer notwendig, auch wenn sie noch experimentell waren, da sie eine Lücke in der Reaktivitäts-Story von Angular schließen. Ohne sie, also wenn man nur mit Signals arbeitet, gibt es keine Möglichkeit, Daten als Teil des reaktiven Flusses abzurufen. Dafür benötigen wir Resources und eine ganz neue HTTP-Resource; das verknüpfte Signal liefert uns eine lokale Arbeitskopie. Das ist zum Beispiel notwendig, wenn schreibgeschützte Daten aus einem Store in ein vorlagengesteuertes Formular eingebunden werden sollen. Da Formulare Werte aktualisieren müssen und schreibgeschützte Signals nicht direkt geändert werden können, bieten uns verknüpfte Signals eine lokale Arbeitskopie. Wir können uns daran binden, Änderungen lokal vornehmen und dann alle Daten zurück an den Store oder direkt an das Backend senden. Ich habe auch die neue Hydration-Story und das hybride Rendering ausprobiert, bei dem wir auf der Ebene einzelner Routen entscheiden können, ob diese Route serverseitig, clientseitig oder während des Builds vorgerendert werden soll. In Kombination mit Incremental Hydration sorgt dies für einen erheblichen Leistungsschub, da die Ladezeiten der Seite verkürzt werden. Wenn eine App im Internet verfügbar ist, sind schnelle initiale Ladezeiten entscheidend, und jede Millisekunde zählt.
Ines Chargui: Das führt mich zu meiner nächsten Frage: Wie beurteilst du Angulars aktuelle Position in Bezug auf Hydration und Resumability?
Manfred Steyer: Ich denke, wir sind hier auf einem wirklich guten Weg. Es ist jetzt möglich, eine Seite inkrementell zu hydrieren, das heißt, man lädt zunächst statisches HTML, und anschließend werden verschiedene Teile der Seite zu unterschiedlichen Zeitpunkten hydriert, abhängig von ihrer Wichtigkeit und davon, womit die Nutzer tatsächlich interagieren.
Wenn ein:e Nutzer:in zum Beispiel noch nicht zu einem bestimmten Abschnitt gescrollt hat, muss dieser Teil nicht sofort hydriert werden. Sicher, serverseitiges Rendering war schon immer möglich, aber ehrlich gesagt war die Entwickler-Erfahrung nicht gerade optimal. Doch jetzt, zum Teil dank des freundlichen Wettbewerbs durch andere Frameworks wie Qwik, hat sich das Ökosystem gewandelt. Angular hat sich schnell weiterentwickelt, und wir sehen bereits deutliche Verbesserungen. Die Developer Experience hat sich stark verbessert und Funktionen wie die inkrementelle Hydration kommen der Resumability deutlich näher.
Ines Chargui: Hydration und Resumability sind aktuell heiße Themen, und Frameworks wie React und Angular verfolgen dabei unterschiedliche Ansätze. Glaubst du, es lohnt sich, weiterhin in diesen Bereich zu investieren, oder besteht die Gefahr, dass das Ganze in einer Sackgasse endet?
Manfred Steyer: Ich glaube nicht, dass wir schon am Ende angelangt sind. Es gibt verschiedene Ansätze, und Frameworks gehen unterschiedlich damit um. Selbst wenn ein Framework von „Hydration“ spricht, muss man genau hinsehen und prüfen, was genau damit gemeint ist. Die Umsetzung kann variieren, doch das Ziel bleibt stets dasselbe: die Menge an JavaScript zu minimieren, die heruntergeladen werden muss, bevor die Nutzer:in die Seite verwenden kann. JavaScript ist großartig für UI/UX, kann jedoch das initiale Laden der Seite verlangsamen. Deshalb waren Single-Page-Applications im Bereich öffentlicher Kundenportale schon immer etwas kritisch, denn in solchen Szenarien zählt jede Millisekunde.
Bei internen Anwendungen, die regelmäßig in einem Unternehmen genutzt werden, ist das kein großes Problem, da die Anwendung nach dem ersten Laden im Browser zwischengespeichert wird. Für öffentliche Websites ist Geschwindigkeit jedoch sehr wichtig. Ich denke, verschiedene Frameworks bewegen sich in die richtige Richtung, indem sie es erleichtern, schnellere und effizientere öffentliche Portale zu erstellen. Die Reaktivitätsmodelle, die diese Frameworks verwenden, können auch dabei helfen, das Laden von Daten hinauszuzögern. Das initiale Rendering soll nicht verzögert werden, aber es kann sinnvoll sein, das Laden bestimmter Daten aufzuschieben.
Ines Chargui: Welche Rolle spielt die Angular-Community bei der Gestaltung des Frameworks, und wie können Entwickler:innen zur Weiterentwicklung von Angular beitragen?
Manfred Steyer: Angular ist ein Open-Source-Projekt, das heißt, jeder kann jederzeit ein Issue eröffnen und Pull Requests einreichen. Das Angular-Team reagiert auch in den sozialen Medien sehr schnell. Wenn du ihnen eine Nachricht schickst, besteht eine gute Chance, dass du direkt von einem Teammitglied eine Antwort erhältst.
Außerdem gibt es einen offiziellen RFC-Prozess. Bevor große Änderungen vorgenommen werden, formuliert das Team seine Ideen und Ziele schriftlich und erklärt die Gründe für bestimmte Ansätze. Anschließend kann sich die Community einbringen und Kommentare abgeben. So wurde zum Beispiel der RFC für die neue Ressourcen-API erst kürzlich nach ein bis zwei Monaten geschlossen. Die Community hatte somit mehrere Wochen Zeit, Feedback und Vorschläge einzureichen. Interessant fand ich dabei, wie das Vorgehen gestaltet wurde. Sie veröffentlichten eine experimentelle Version ihrer Vision, noch bevor der RFC-Prozess begann. So hatten Entwickler:innen etwas Konkretes zum Ausprobieren, was es deutlich erleichterte, nützliches und fundiertes Feedback zu geben. Ich selbst habe das Ganze getestet, indem ich eine erste Beispielanwendung gebaut habe – das hat mir sehr dabei geholfen, konkreteres Feedback zu formulieren. Es war ein kluger Schachzug, der sich positiv auf die Qualität der Rückmeldungen ausgewirkt hat.
Ines Chargui: Welchen Einfluss hat Angular auf die Barrierefreiheit, wenn das neue EU-Gesetz zur Barrierefreiheit in Kraft tritt? Berücksichtigt das Team diesen Aspekt bei der Einführung neuer Tools oder Verbesserungen, um die Zugänglichkeit von Angular-Anwendungen zu verbessern?
Manfred Steyer: Ich würde sagen, Angular ist als Framework weitgehend neutral in Bezug auf Barrierefreiheit. Es kommt darauf an, wie man es einsetzt, um eine Anwendung zu entwickeln und sie barrierefrei zu gestalten. Wenn man sich Angular Material ansieht – die offizielle Komponentenbibliothek, die vom Angular-Team gepflegt und innerhalb von Google eingesetzt wird –, zeigt sich, dass Barrierefreiheit von Anfang an ein zentraler Schwerpunkt war. Die Komponenten basieren auf korrekt verwendetem semantischem Markup und unterstützen neben anderen Funktionen zur Barrierefreiheit auch die vollständige Tastaturnavigation.
Auch wenn Angular als Framework Barrierefreiheit nicht standardmäßig erzwingt, legt Angular Material großen Wert darauf, seine Komponenten barrierefrei zu gestalten.
Ines Chargui: Welche Angular-Funktionen gehören zu deinen Favoriten oder sollten deiner Meinung nach von jeder Entwickler:in unbedingt beherrscht werden?
Manfred Steyer: Nun, ich würde sagen, dass die Datenbindung einer der wichtigsten Punkte ist. Die meisten nutzen Angular vor allem deshalb, weil es Datenbindung von Haus aus bietet. Wer das manuell umsetzt, muss mit viel Aufwand rechnen, und der Code wird dabei oft unübersichtlich und schwer wartbar. In letzter Zeit hat mir die neue Signalfunktion besonders gut gefallen. Sie bietet einen intuitiveren Ansatz für Reaktivität und erleichtert es, den Datenfluss in der Anwendung zu optimieren. Ich war auch schon immer ein großer Fan des Angular Routers und aller Funktionen rund um den HTTP-Zugriff, denn gerade in diesem Bereich überzeugt Angular nach wie vor. Und schließlich – vielleicht nicht das Aufregendste, aber auf jeden Fall unerlässlich – die Formularunterstützung. Besonders in Unternehmensanwendungen, in denen man mit vielen Formularen arbeitet, ist die Formularunterstützung von Angular von Anfang an unglaublich hilfreich.
Ines Chargui: Mich interessiert, wie viel du mit anderen, neuen Frameworks experimentieren konntest. Was hältst du von diesen neueren, minimalistischen Modellen?
Manfred Steyer: Ich denke, diese neueren, jungen Frameworks sind wirklich wichtig. In der Vergangenheit waren sie oft der Auslöser dafür, dass sich Angular und andere große Frameworks weiterentwickeln und neu ausrichten mussten. Sie bringen neue Ideen ein und zeigen, dass man mit einer anderen Denkweise in bestimmten Bereichen manchmal mehr erreichen kann. So gesehen sind sie oft der Ursprung neuer Entwicklungen.
Allerdings halte ich es für schwierig, dass ein neues Framework wirklich Fuß fasst. Es braucht eine kritische Masse an Nutzer:innen und Mitwirkenden. Frameworks wie Angular oder React haben diese Größe bereits erreicht, was ihnen langfristige Stabilität verleiht. Aus praktischer Sicht werden Angular, React oder Vue wahrscheinlich noch viele Jahre bestehen bleiben, egal für welches Framework Sie sich entscheiden. Doch auch die kleineren Frameworks, wie zum Beispiel Qwik, spielen weiterhin eine wichtige Rolle. Sie fordern die großen Player heraus, sich zu hinterfragen, anzupassen und neu zu erfinden. Bislang haben wir gesehen, dass sie dieser Herausforderung gewachsen sind.
Ines Chargui: Trotz Angulars großer Beliebtheit, all der Verbesserungen und seiner stetigen Weiterentwicklung, schafft es das Framework in Entwicklerumfragen nie unter die drei oder sogar fünf meistgenutzten Frameworks. Wie erklärst du dir das?
Manfred Steyer: Guter Punkt. Ich denke, das korreliert mit dem, was ich bereits vorher gesagt habe. Wenn du als typische:r Webentwickler:in an Webprojekten oder Portalen arbeiten, kann Angular manchmal zu umfangreich wirken, und viele bevorzugen eher leichtgewichtige Lösungen. Würde man jedoch dieselbe Umfrage unter Unternehmensentwickler:innen durchführen, bin ich mir ziemlich sicher, dass die Ergebnisse ganz anders ausfallen würden. In Branchen wie dem Bankwesen, der Versicherungsbranche oder der Fertigungsindustrie ist Angular weit verbreitet. Ich denke auch, dass sich das Angular-Team der Wahrnehmung bezüglich der Komplexität bewusst ist und daran arbeitet, unnötigen Ballast zu reduzieren.
Ines Chargui: Blicken wir etwas in die Zukunft: Wie stellst du dir die Weiterentwicklung von Angular vor? Gibt es vielleicht etwas, das derzeit nicht auf dem Radar des Teams ist, von dem du als Entwickler aber glaubst, dass es einen großen Unterschied machen würde?
Manfred Steyer: Ich sehe drei Richtungen: Zum einen Verbesserungen im gesamten Bereich des inkrementellen Renderns, einschließlich der inkrementellen Hydration. Zum anderen steht die Reaktivität noch am Anfang, birgt aber viel Potenzial, insbesondere mit der Einführung von Signals. Ein großer Schritt wäre zum Beispiel, Router, Formulare und das Laden von Daten an Signals anzupassen. Diese Art von Reaktivität könnte viele neue Muster ermöglichen. Letztlich werden die beiden Bereiche –inkrementelles Rendering und Reaktivität – zusammenwachsen. Denn wenn inkrementelles Rendering verfügbar ist, wird früher oder später auch inkrementelles Datenabrufen erforderlich – und genau dort kommt Reaktivität ins Spiel.
Ein weiterer Bereich ist die Developer Experience. Dazu zählen etwa Verbesserungen am Build-Prozess, schnellere Abläufe, mehr Funktionen auf Abruf oder das Umschreiben von Compilern in nativen Sprachen. TypeScript wurde inzwischen in Go neu geschrieben, und ich würde mir etwas Vergleichbares für den Angular-Compiler wünschen. Das würde den gesamten Build-Prozess beschleunigen, was für große Teams oft ein zentrales Problem darstellt.
Ines Chargui: KI ist derzeit ein großes Thema und wird in irgendeiner Form von allen genutzt. Was hältst du von der Integration von KI in JavaScript? Genauer gesagt, wie siehst du den Einsatz von KI in Angular-Anwendungen?
Manfred Steyer: Das Angular-Team denkt darüber nach, in Zukunft KI einzusetzen, um bei Code-Migrationen zu unterstützen. Das passt gut zu dem Ziel, bestehende Codebasen möglichst nicht zu brechen. Aktuell werden viele Migrationen über eigene Skripte abgewickelt, was jedoch Grenzen hat, da sich nicht alles automatisieren lässt – besonders dann, wenn es keine direkte Umwandlung vom alten zum neuen Stil gibt. Das automatisch durchzuführen ist etwas schwierig, daher könnte KI hier wirklich helfen. Sie kann den aktuellen Quellcode analysieren und herausfinden, welche Anpassungen nötig sind, um den Code an die neuesten Versionen aller Bibliotheken anzupassen.
Ines Chargui: Das hat zwar nichts direkt mit Angular zu tun, aber was hältst du von diesen KI-Bibliotheken wie TensorFlow.js oder Brain.js?
Manfred Steyer: Ich denke, Webentwickler:innen werden lernen, KI-Modelle zu nutzen, egal ob auf der Serverseite oder direkt im Browser. Die Idee ist, bestimmte Aufgaben an diese Modelle zu delegieren, um einen Mehrwert für die Nutzer:innen zu schaffen, beispielsweise das automatische Ausfüllen von Formularen, das Ableiten von Werten, die Analyse von Bildern und Ähnliches.
Wenn ich beispielsweise meine Aktivitäten für das GDE-Programm (Google Developer Experts) berichte, muss ich abschätzen, wie viele Personen an meinen Konferenzvorträgen teilgenommen haben. Ich könnte einfach ein Foto hochladen, es von einer KI auswerten lassen, die die Personen darauf zählt, und so eine deutlich genauere Zahl erhalten. Ich denke, wir können noch mehr tun, um die gesamte Nutzererfahrung zu verbessern, insbesondere indem wir repetitive Aufgaben eliminieren. Ein weiterer Bereich mit Verbesserungspotenzial ist die Entwicklererfahrung, denn Tools wie GitHub und Copilot verändern, wie wir Code schreiben, und machen diesen Prozess schneller und intuitiver.
Ines Chargui: Möchtest du sonst noch etwas zu Angular ergänzen?
Manfred Steyer: Eine letzte Sache: Es ist jetzt möglich, Komponenten dynamisch zur Laufzeit zu erstellen. Das war vorher nicht wirklich möglich, da Angular eine kompilierte Sprache ist und die Generierung von Komponenten zur Laufzeit offiziell nicht unterstützt wurde. Natürlich kann man, wenn man versteht, was der Compiler zur Kompilierungszeit macht, zur Laufzeit etwas Ähnliches zusammenbasteln, um dynamische Komponenten zu erzeugen. Das wurde aber nie offiziell unterstützt. Jetzt gibt es dafür eine offizielle API, was sehr spannend ist.
Ines Chargui: Vielen Dank, dass du dir die Zeit für das Gespräch genommen hast!
