Angular in Deutschland: Warum der Enterprise-Standard im KI-Zeitalter teurer wird
Warum Angular in Deutschland so stark wurde, was Signals verändert haben und was Nolan Lawsons Messung über die Kosten von Coding-Agenten pro Framework zeigt.
Bernd D.H. Martin
In Deutschland war Angular lange der Standard, wenn es um große Webanwendungen ging. Jetzt zeigt eine Messung von Nolan Lawson, dass dasselbe Framework für Coding-Agenten am teuersten ist. Das ist keine Kritik an Angular, aber es passt zu einer Frage, die ich mir gerade stelle: Was zählt bei der Wahl eines Frameworks, wenn ein Agent einen Großteil des Codes schreibt?
Der erste Teil ist meine eigene Einschätzung aus der Praxis, nicht belegt durch Zahlen. Der zweite Teil stützt sich auf Lawsons Messung, die ich unten verlinke.
Warum Angular in Deutschland so stark wurde
In den USA und in der Start-up-Szene war React oft die pragmatische Wahl. In Deutschland wurde Angular zum Enterprise-Standard. Ich sehe dafür vier Gründe:
- Konzernstrukturen: Banken, Versicherungen, Automotive und der Mittelstand mögen Umgebungen mit klaren Regeln. „Batteries included“ ist für sie ein Vorteil, nicht eine Einschränkung.
- Vertrauter Stallgeruch: Viele Entwickler kamen aus der Java- oder C#-Welt. TypeScript, Dependency Injection, eine feste Modulstruktur und Decorators passen zu dem, was sie schon kannten.
- Standardisierung in Projekten: Systemhäuser und Beratungen setzen gern auf ein einheitliches Gerüst, damit sich Leute zwischen Projekten austauschen lassen.
- Planungssicherheit: Feste Release-Zyklen, Langzeitunterstützung und Google als Hersteller beruhigen konservative IT-Abteilungen.
Was Signals verändert haben
Angular hatte lange den Ruf, schwer und voller Boilerplate zu sein. Für einfachen UI-Zustand brauchte man schnell RxJS-Streams oder einen NgRx-Store. Mit Signals hat sich das spürbar verbessert:
- Feingranulare Reaktivität: Statt breiter Change Detection über Zone.js werden nur die Teile des DOM aktualisiert, deren Signal sich geändert hat.
- Weniger Boilerplate: Lokalen Zustand und abgeleitete Werte schreibt man mit
signal()undcomputed(), ohne Ketten aus Observables. - RxJS als Spezialwerkzeug: RxJS bleibt dort, wo es stark ist, etwa bei komplexen asynchronen Event-Streams und WebSockets, und ist nicht mehr für jeden Alltagsfall nötig.
Für Teams heißt das: Sie bekommen eine modernere Entwicklererfahrung, ohne die Struktur des Frameworks aufzugeben.
Was Lawson gemessen hat
Nolan Lawson hat in „The AI cost of JavaScript frameworks“ (28. Oktober 2026) denselben kleinen App-Auftrag, eine Pokédex-App, mit Claude Code und Opus 5.5 in zwölf Stacks bauen lassen, je fünfmal. Die Tabelle zeigt den Median pro Lauf:
| Stack | Kosten | Tokens | Zeit |
|---|---|---|---|
| Hono + htmx | 2,67 $ | 4,26 Mio. | 8,6 Min. |
| Nuxt | 2,82 $ | 3,85 Mio. | 9,0 Min. |
| Next.js | 3,14 $ | 4,99 Mio. | 10,9 Min. |
| Angular | 4,97 $ | 9,76 Mio. | 17,2 Min. |
Die Tabelle ist ein Auszug. Bei Lawson sind alle zwölf Stacks aufgeführt, darunter Astro, SvelteKit und React Router. Außerdem lag Angular beim Code am höchsten, mit im Median 2.009 Zeilen gegenüber 1.370 bei Hono + htmx.
Was bei den Zahlen zu beachten ist:
- Die Dollarbeträge sind API-Preise, die Claude Code anzeigt. Lawson selbst war mit einem Abo von 100 Dollar im Monat unterwegs und hat nicht diese Summen bezahlt.
- Die Streuung ist groß. Der günstigste Angular-Lauf (3,19 $) kostete so viel wie der teuerste Lauf von Hono + htmx. Lawson schreibt selbst, dass seine Messwerte sehr zufallsabhängig sind.
- Angular hat zweimal keine messbare App geliefert. Deshalb stammen einige seiner Werte aus drei statt fünf Läufen.
- Bei Lighthouse (Performance und Barrierefreiheit) lagen alle Stacks nahe 100. Die Mehrkosten haben sich in dieser kleinen App also nicht als bessere Qualität gezeigt.
Als Grund für die hohen Angular-Kosten nennt Lawson, dass es offenbar mit der Gesamtmenge an Code zusammenhängt. Bei SvelteKit und Gracile + Lit sieht er andere Ursachen: Die Agenten haben dort Migrationsanleitung beziehungsweise Quellcode des Frameworks gelesen.
Meine Vermutungen dazu
Das Folgende sind Vermutungen von mir, die Lawson so nicht gemessen hat:
- Viel Struktur wie Moduldeklarationen, Decorators und viele Dateien bedeutet mehr Kontext, und den muss der Agent bei jedem Lesen und Ändern neu laden.
- Komplexe Abstraktionen wie lange RxJS-Pipelines oder verschachtelte Dependency Injection machen Fehler wahrscheinlicher, und jede Korrekturschleife kostet noch einmal Tokens.
Ob das stimmt, könnte ich nur mit einem eigenen Vergleich sagen. Das habe ich nicht gemacht.
Was ich daraus mitnehme
Lange war Struktur der Vorteil von Angular, weil sie vielen Menschen Leitplanken gegeben hat. Bei einem Agenten kann dieselbe Struktur zusätzliche Kosten und Zeit bedeuten. Standalone Components und Signals machen neuen Angular-Code schlanker, das bildet Lawsons Test aber nicht einzeln ab. Mehr als „Angular ist hier im Schnitt am teuersten“ lese ich aus seinen Zahlen nicht heraus.
Für mich ist interessant, dass Nuxt, worauf auch bmline.de läuft, in dieser Messung im vorderen Feld lag: zweitgünstigste Kosten und die wenigsten Tokens. Das ist ein Zufallsfund und kein Grund für eine Wahl, aber ein weiterer Hinweis, bei einem neuen Projekt auch den Aufwand für den Agenten mitzudenken.
Quellen
- Nolan Lawson: The AI cost of JavaScript frameworks, 28.10.2026