Angular 22 einordnen

Angular 22 einordnen

0:00 Wer aus JavaScript und TypeScript kommt, hat Angular meistens schon einmal von außen gesehen — und dabei einen Eindruck gewonnen, der vielleicht fünf Jahre alt ist. Genau deshalb fangen wir nicht bei den Komponenten an, sondern einen Schritt davor. Angular ist in den letzten drei Hauptversionen an einigen Stellen ein anderes Framework geworden, und wer das nicht weiß, baut mit den Mitteln von gestern.

0:21 In diesem Modul klären wir, was Angular eigentlich ist, welche Version wir vor uns haben, wie lange sie uns trägt — und welche Annahmen ein neues Projekt heute schon mitbringt, ohne dass jemand sie einschaltet.

Angular verstehen und eine Anwendung aufbauen

0:33 Der erste Tag hat zwei Hälften. In der ersten ordnen wir ein: Was gehört zu Angular, welche Version gilt, wie ist ein Projekt geschnitten. In der zweiten bauen wir die ersten Bausteine — Komponenten und Templates. Am Ende des Tages steht ein lauffähiges Projekt mit einer Auftragsübersicht. Alles, was danach kommt, wächst in genau diesem Projekt weiter.

Angular als Anwendungsframework

0:55 Fangen wir mit der Frage an, die überraschend oft übersprungen wird: Was bekommen Sie eigentlich, wenn Sie sich für Angular entscheiden? Die Antwort ist nämlich breiter, als der Vergleich mit anderen Frontend-Werkzeugen vermuten lässt — und sie erklärt einige Entscheidungen, die sonst willkürlich wirken. Stellen Sie sich den Unterschied zwischen einem Werkzeugkasten und einer eingerichteten Werkstatt vor.

1:18 Im Werkzeugkasten suchen Sie sich zusammen, was Sie brauchen — Hammer hier, Säge dort, und Sie achten selbst darauf, dass alles zueinander passt. Die Werkstatt ist schon eingerichtet: Die Geräte stehen da, sie sind aufeinander abgestimmt, und wenn modernisiert wird, dann gemeinsam. Angular ist die Werkstatt. Router, Formulare, Datenzugriff, Dependency Injection, ein eigener Template-Compiler und die Kommandozeile kommen aus einer Hand und werden gemeinsam versioniert.

1:45 Das nimmt Ihnen Entscheidungen ab — und gibt Ihnen im Gegenzug Struktur vor. Diese vier Schichten sind keine Architektur, die Sie bauen müssen — sie sind da, sobald Sie ein Projekt anlegen. Interessant ist die Leserichtung von unten nach oben. Ganz unten stehen die Werkzeuge: Kommandozeile, Compiler, Test-Runner. Darüber die Laufzeit mit Dependency Injection und Change Detection — der Teil, den Sie selten direkt anfassen und der trotzdem über das Verhalten Ihrer Anwendung entscheidet.

2:14 Dann die Bausteine, die Sie aktiv benutzen. Und erst ganz oben Ihre eigene Anwendung. Wenn später etwas unerklärlich wirkt, liegt die Ursache fast immer eine Schicht tiefer, als man zuerst schaut. Der praktische Gewinn zeigt sich nicht am ersten Tag, sondern im dritten Jahr. Ein Update hebt alle Teile gemeinsam — Sie pflegen nicht vier Abhängigkeiten, die sich gegenseitig blockieren können.

2:38 Der Compiler prüft Ihre Templates mit, nicht nur den TypeScript-Code, und findet dabei Fehler, die anderswo erst zur Laufzeit auffallen. Und Router, Formulare und Datenzugriff sind nicht jedes Mal eine Auswahlentscheidung, die jemand recherchieren und verantworten muss. Der Preis dafür ist Verbindlichkeit: Angular gibt Struktur vor, wo eine Bibliothek Sie machen lässt.

2:59 Für ein Team, das eine Anwendung über Jahre pflegt, ist das eher Gewinn als Einschränkung. Die häufigste Falle ist der erste Punkt, und er kommt fast immer von Umsteigern: Angular wird wie eine Render-Bibliothek behandelt und großzügig um Fremdteile ergänzt — eine eigene Zustandsverwaltung, ein fremdes Formularpaket, ein zusätzlicher Datenabruf.

3:19 Dann hat man beides und nutzt keines richtig. Der zweite Punkt ist subtiler: Weil Templates viel können, wandern fachliche Entscheidungen dorthin — und sind dort nicht mehr testbar. Und der dritte kostet die meiste Zeit: Beispiele aus dem Netz stammen oft aus älteren Hauptversionen. Sie funktionieren, sind aber nicht mehr das, was Angular heute empfiehlt.

Versionen, Support und Releaseplanung

3:40 Kommen wir zu einer Frage, die im Projektalltag gern liegen bleibt, bis sie dringend wird: Welche Version haben wir eigentlich, und wie lange trägt sie uns noch? Angular macht es einem an dieser Stelle leicht — der Rhythmus ist seit Jahren derselbe und gut dokumentiert. Angular arbeitet mit einem Fahrplan, den man sich merken kann: eine Hauptversion pro Jahr, dazwischen vier bis sechs kleinere Versionen und fast wöchentlich ein Patch.

4:05 Jede Hauptversion wird zwölf Monate aktiv gepflegt — da kommen Verbesserungen und Korrekturen. Danach folgen zwölf Monate Langzeitsupport, in denen es nur noch kritische Fehler und Sicherheitslücken sind. Insgesamt also 24 Monate. Denken Sie an eine Garantie mit zwei Stufen: In der ersten wird repariert und nachgebessert, in der zweiten nur noch das, was wirklich gefährlich wäre.

4:28 Die Zahlen in dieser Tabelle sind weniger interessant als das Muster dahinter. Lesen Sie die Spalte „Aktiv bis" als Ihren Kalender. Sie sehen drei Versionen, und das ist kein Zufall — es sind immer genau drei: eine aktive und zwei im Langzeitsupport. Sobald die nächste Hauptversion erscheint, fällt die älteste heraus. Für Sie heißt das: Wer heute auf der aktiven Version steht, hat bis zum nächsten Pflichtupdate ein knappes Jahr Luft.

4:55 Wer zwei Versionen zurückliegt, sollte den Termin im Projektplan haben — und zwar nicht als Wunsch, sondern als Datum. Drei Konsequenzen, die man am besten einmal ausspricht. Erstens: Ihr Projekt bleibt höchstens 24 Monate ohne Update im unterstützten Bereich. Danach bekommen Sie auch keine Sicherheitspatches mehr — und das ist der Punkt, an dem aus einer technischen Frage eine Risikofrage wird.

5:20 Zweitens: Ein Sprung über zwei Hauptversionen sind zwei Updates, nicht eines. Man kann das nicht abkürzen, und wer es versucht, überspringt Migrationen, die dann fehlen. Drittens: Der Terminplan nennt künftige Versionen, bestätigt aber keine Veröffentlichung. Ein angekündigtes Datum gehört nicht in eine Projektplanung, als wäre es bereits eingetreten.

5:42 Alle drei Fallen haben dieselbe Wurzel: Der Versionsstand wird als Momentaufnahme behandelt, nicht als etwas, das weiterläuft. Ein geplanter Termin landet im Projektplan wie eine erschienene Version — und dann verschiebt sich der Termin. Das Update wird aufgeschoben, bis die Version den Support verlassen hat, und plötzlich ist es kein Update mehr, sondern ein Projekt.

6:04 Und der Stand wird einmal geprüft und danach als dauerhaft gültig angenommen. Dagegen hilft nur eines, und es kostet fünf Minuten: das Enddatum der aktiven Phase aufschreiben, mit Datum der Prüfung daneben.

Kompatibilität mit Node.js und TypeScript

6:16 Zur Version gehört ein zweiter Teil, der noch häufiger übersehen wird — nämlich das, was drumherum laufen muss. Und anders als man vermuten würde, ist das keine Empfehlung, sondern eine Festlegung. Zu jeder Angular-Version gehören feste Bereiche für Node, TypeScript und RxJS. Das ist keine Empfehlung im Sinne von „läuft am besten mit" — es ist eine Zusage, die nur innerhalb dieser Bereiche gilt.

6:41 Angular 22 verlangt TypeScript ab Version 6.0 und unterhalb von 6.1, also eine sehr enge Spanne, dazu bestimmte Node-Versionen. Der tückische Teil: Eine Abweichung führt selten zu einer klaren Fehlermeldung. Sie bekommen stattdessen ein merkwürdiges Verhalten an einer Stelle, die mit der Ursache nichts zu tun hat — und suchen dort stundenlang.

7:03 Schauen Sie nicht auf die einzelnen Zahlen, sondern auf die Bewegung zwischen den Zeilen. Von Version 21 auf 22 springt TypeScript über eine Hauptversion, und die Node-Anforderung zieht spürbar an. Das ist typisch: Angular folgt den Plattformen relativ eng. Für Sie bedeutet das zweierlei. Erstens: Ein Angular-Update ist fast nie nur ein Angular-Update — die Build-Umgebung zieht mit.

7:27 Zweitens: Wenn Sie den Sprung planen, prüfen Sie diese Tabelle vor dem Sprung, nicht danach. Und zwar für die Zielversion, nicht für die aktuelle. Der rote Faden dieser vier Schritte ist einer: aus einer Information eine Festlegung machen. Sie lesen die Matrix — das ist die Information. Dann schreiben Sie die Node-Version im Projekt fest, statt sie der jeweiligen Entwicklungsmaschine zu überlassen.

7:51 Sie begrenzen die TypeScript-Version in der Paketdatei auf den erlaubten Bereich, statt sie offen nach oben laufen zu lassen. Und Sie halten den Stand mit Datum fest, damit beim nächsten Mal nachvollziehbar ist, wann jemand zuletzt geschaut hat. Ohne diese drei Schritte haben Sie recherchiert, aber nichts verändert. Der erste Punkt ist der Klassiker schlechthin: Die global installierte Node-Version weicht von der des Projekts ab.

8:16 Das ist die häufigste Ursache für Fehler, die nur bei einer Person auftreten — und die deshalb besonders lange ungeklärt bleiben. Der zweite: TypeScript wird über den erlaubten Bereich hinaus angehoben, meistens weil ein anderes Paket es verlangt. Dann arbeiten Sie außerhalb der Zusage, ohne es zu merken. Und der dritte: Die Matrix wird beim Update der Anwendung geprüft, aber nicht beim Update der Werkzeuge drumherum.

Heutige Standardannahmen für neue Anwendungen

8:40 Jetzt zum Teil, der für Umsteiger am meisten verändert: Was bringt ein neues Angular-Projekt eigentlich schon mit? Und zwar nicht als Option, die Sie einschalten könnten, sondern als Voreinstellung. Hier steckt die wichtigste Nachricht dieses Moduls. Ein neues Angular-Projekt ist standalone — die Klammer namens NgModule, über die früher alles lief, brauchen Sie nicht mehr.

9:03 Es läuft ohne Zone.js, also ohne die Bibliothek, die früher jede asynchrone Operation überwacht hat. Und OnPush, früher eine bewusste Optimierung, ist die Standardstrategie. Dazu kommen Signal Forms, Angular Aria und die Ressourcen-APIs als ausgereifte Mittel, und Vitest als Test-Runner. Wichtig ist das Wort „Voreinstellung": Sie schalten das nicht ein. Es ist da.

9:27 Diese Gegenüberstellung ist der Grund, warum Sie beim Suchen im Netz vorsichtig sein müssen. Die linke Spalte ist nicht falsch — sie funktioniert, sie ist in Tausenden von Anwendungen im Einsatz, und sie wird weiter unterstützt. Aber sie ist nicht mehr das, was Angular empfiehlt. Das Problem für Sie: Zu jedem dieser vier Punkte finden Sie im Netz beide Varianten, und die ältere ist häufiger, weil sie länger existiert.

9:50 Wer neu anfängt, sollte sich deshalb an der rechten Spalte orientieren — und beim Kopieren aus fremden Beispielen kurz prüfen, aus welcher Welt sie stammen. Der eigentliche Vorteil für Sie ist, dass Sie genau einen Weg lernen statt zweier Generationen nebeneinander. Wer Angular vor drei Jahren angefangen hat, musste beides kennen — die alte Welt, weil der Bestand so aussah, und die neue, weil sie empfohlen wurde. Sie fangen direkt rechts an.

10:16 Bestehende Anwendungen dürfen beides zugleich enthalten, und das ist auch völlig in Ordnung; niemand schreibt eine gewachsene Anwendung an einem Wochenende um. Aber eine neue sollte es nicht. Wie eine bestehende Anwendung schrittweise dorthin kommt, ist ein eigenes Thema — und bekommt an Tag sechs ein eigenes Modul. Alle drei beschreiben, wie die alte Welt zurückkommt, ohne dass es jemand beschließt.

10:40 Ein Beispiel aus dem Netz bringt NgModule und Dekoratoren ins neue Projekt — und weil es funktioniert, bleibt es. Zone.js wird über eine Abhängigkeit wieder eingezogen, meistens über ein Paket, das noch nicht umgestellt wurde. Und der dritte Punkt ist der, der die beiden anderen überhaupt erst ermöglicht: Die Standardannahmen werden im Team nie festgehalten.

11:00 Dann weiß niemand, ob eine Abweichung eine Entscheidung war oder ein Versehen — und beides sieht im Code gleich aus.

Übung

11:08 Genug eingeordnet. Machen wir daraus etwas Verbindliches — und lernen dabei gleich die Anwendung kennen, die uns die ganze Woche begleitet. Wir arbeiten die ganze Woche an einer Anwendung, und ich möchte sie Ihnen kurz vorstellen, weil jede Übung darauf aufbaut. Die Falkenhorst Fahrzeugtechnik betreibt 34 Werkstattstandorte mit rund 1.400 Beschäftigten.

11:30 Reparaturaufträge werden heute je Standort in einer Tabellenkalkulation geführt — mit allem, was dazugehört: keine gemeinsame Sicht, keine Historie, und wenn jemand im Urlaub ist, findet niemand die Datei. Das interne Portal Spurweite soll das ablösen. Eine unspektakuläre Anwendung, absichtlich: Sie braucht Liste und Detail, Formulare, Navigation, Datenzugriff und Tests — also genau alles, was wir behandeln.

11:56 Sie schreiben den Versionsstand für Spurweite fest. Das klingt nach Verwaltung, ist aber die Übung, in der sich zeigt, ob die Unterscheidung zwischen Information und Festlegung angekommen ist. Das Erfolgskriterium nennt vier Dinge: Angular-, Node- und TypeScript-Bereich mit Quelle und Datum — und den Monat, in dem der Support endet.

12:15 Dieser letzte Punkt ist mir der wichtigste, denn er ist der einzige, der später einen Anlass erzeugt. Ein Versionsstand ohne Enddatum sagt Ihnen, wo Sie stehen. Mit Enddatum sagt er Ihnen, wann Sie sich wieder kümmern müssen. Fünf Schritte, und die ersten drei sind schnell erledigt: nachschlagen, übernehmen, festschreiben.

12:35 Der vierte ist der interessante — Sie gehen die vier Standardannahmen durch und begründen je Zeile ein Ja oder ein Nein. Nicht, weil eine davon strittig wäre, sondern weil das Aufschreiben aus einer Selbstverständlichkeit eine Entscheidung macht. In sechs Monaten kann dann jemand nachlesen, ob zoneless eine Wahl war oder einfach passiert ist. Und der fünfte Schritt kostet zehn Sekunden: datieren.

12:58 Ohne Datum weiß niemand, ob das Dokument von letzter Woche ist oder von vor zwei Jahren. Ich nenne Ihnen die drei Fehler, die Sie gleich machen werden, damit Sie sie nicht machen. Erstens: Der Steckbrief nennt eine Angular-Version, aber nicht die zugehörigen Node- und TypeScript-Bereiche — dann ist er die Hälfte wert, weil genau dort die Fehler entstehen.

13:19 Zweitens: Das Supportende fehlt, und damit fehlt der Anlass für das nächste Update. Drittens: Die Standardannahmen werden übernommen, ohne sie zu benennen. Wenn Sie nur eine Sache mitnehmen: Schreiben Sie auf, was Sie voraussetzen. Als Nächstes bauen wir daraus ein Projekt — mit einem Zuschnitt, der in zwei Jahren noch trägt.