Heise Developer: Angular Signals: Elegante Reaktivität als Architekturfalle

Veröffentlicht am 10. August 2025 - ⏱️ Ca. (wird berechnet) min. Lesezeit

Angular Signals sind eine der spannendsten Neuerungen im Angular-Ökosystem. Ihre schlanke Syntax, die enge Anbindung an das Template und der Verzicht auf manuelles Subscription-Handling machen sie zu einem mächtigen Werkzeug – aber gerade deshalb auch zu einem gefährlichen.

Denn wer einmal erlebt hat, wie effect()-Ketten sich unbemerkt aufschaukeln, wie implizite Abhängigkeiten entstehen oder wie durch scheinbar harmlose Refactorings ganze Reaktionspfade verschwinden, weiss: Die Technik selbst ist korrekt. Ihr Einfluss auf Architektur und Teamverhalten aber nicht trivial.

Genau deshalb habe ich den Artikel „Angular Signals: Elegante Reaktivität als Architekturfalle“ auf heise Developer veröffentlicht: Um aufzuzeigen, wo die Grenzen dieser neuen Reaktivitätsform liegen. Nicht theoretisch, sondern anhand konkreter Beispiele aus realen Projekten. Der Text will ein Bewusstsein dafür schaffen, wie technische Vereinfachung zu architektonischer Instabilität führen kann, wenn der Kontext fehlt.

Warum der Artikel notwendig ist

Der Text basiert nicht auf Hypothesen, sondern auf Beobachtungen aus realen Codebasen. In Projekten, Reviews und Workshops:

• Effekte, die mehrfach pro Sekunde feuern, ohne erkennbare Ursache
• API-Calls, die durch effect() ausgelöst und nie abgebrochen werden
• Komponenten, die sich plötzlich inkonsistent verhalten
• Entwickler, die computed()-Abhängigkeiten nicht mehr nachvollziehen können

Die zentrale These lautet daher nicht: „Signals sind schlecht“, sondern: „Signals laden zu einem Architekturstil ein, der ohne bewusstes Gegengewicht entgleisen kann.“

Reaktionen aus der Community – willkommen, aber oft am Ziel vorbei

Die Kritik kam schnell und sie war fundiert, technisch detailliert und voller guter Intention. Eine der prominentesten Rückmeldungen formulierte es so:

„Viele Informationen aus diesem Artikel sind schlicht falsch, irreführend und gefährlich!“ Signals seien gar nicht als RxJS-Ersatz gedacht, sondern für State. RxJS hingegen bleibe zuständig für Events. Zudem seien bestimmte beschriebene Probleme entweder gewollt oder technisch lösbar. Etwa durch untracked(), eigene Vergleichslogik oder bewusstes Effekt-Design.

Diese Rückmeldung verdient Anerkennung. Sie bringt technische Tiefe ein, benennt relevante Differenzierungen, und sie zeigt, dass es aktive Community-Mitglieder gibt, die nicht nur meckern, sondern aufklären wollen.

Trotzdem bleibt ein fundamentaler Dissens: Die beschriebenen Probleme sind keine Missverständnisse. Sie sind Realität. Und zwar nicht nur bei Anfängern, sondern auch in erfahrenen Teams. Das Problem ist nicht die Theorie hinter Signals, sondern die Art, wie sie faktisch eingesetzt werden.

Was der Artikel tatsächlich kritisiert

Wer den Artikel vollständig liest, erkennt schnell: Es geht nicht darum, die Signals-API schlechtzureden oder Angulars Architektur zu kritisieren. Im Gegenteil:

„Signals entfalten ihren Wert dort, wo der Zustand lokal ist und die Reaktivität überschaubar bleibt. Strukturierte Architektur oder RxJS ist sinnvoll bei Prozessen mit Abhängigkeiten oder Abbruchlogik.“

Die Kritik richtet sich an eine Praxis, die gerade durch die scheinbare Eleganz der API befördert wird:

• Logik wandert in effect(), ohne Lifecycle-Kontrolle
• Steuerung verläuft implizit über Lesezugriffe, nicht über Intents
• Seiteneffekte werden nicht orchestriert, sondern passieren nebenbei
• Signals übernehmen Aufgaben, für die sie nicht gedacht waren – schlicht, weil sie es können

Der Artikel zeigt diese Dynamiken an einem bewusst lebensnahen Beispiel. Er endet mit einer klaren Einordnung, wann Signals sinnvoll sind und wann nicht.

Warum die Kritik dennoch wertvoll ist

Die Replik benennt technische Schutzmechanismen: untracked(), benutzerdefinierte Vergleichsoperatoren, bewusste Effektgrenzen. Und sie hat recht: All das existiert.

Doch genau darin liegt das eigentliche Problem: Diese Schutzmechanismen sind optional, manuell und nicht standardisiert. Wer sie nicht kennt oder inkonsequent nutzt, riskiert ungewollte Kopplung, schwer debugbare Zustände und instabile Abläufe. Das Design der API begünstigt diesen Wildwuchs. Nicht absichtlich, aber faktisch.

Deshalb heisst es im Artikel auch:

„Diese Lösungen bleiben manuell, individuell und nicht standardisiert. Wer auf architektonischer Ebene Kontrolle über Nebenläufigkeit, Vergleichbarkeit oder Abbruchverhalten benötigt, muss diese Strukturen selbst aufbauen.“

Fazit: Produktive Reibung schafft bessere Software

Der Heise-Artikel versteht sich nicht als Warnung vor Signals, sondern als Einladung zur Reflexion:

• Was machen neue APIs mit unseren Architekturen?
• Wie verändert sich der Code, wenn etwas plötzlich sehr einfach wird?
• Wo endet Vereinfachung und beginnt Vereinseitigung?

Signals sind ein Fortschritt! Vor allem im UI. Doch wer sie in die Steuerlogik hineinzieht, ohne ein architektonisches Gegengewicht zu etablieren, verliert Kontrolle über Fluss, Verantwortung und Kausalität.

Die Kritik, die darauf folgte, war willkommen. Denn genau das war das Ziel: Eine Diskussion zu beginnen, die über die Syntax hinausgeht, hinein in die Systemarchitektur. Angular Signals sind kein Fehler im System. Aber sie machen es leicht, welche zu begehen.

Den ganzen Artikel gibt es auf Heise: „Angular Signals: Elegante Reaktivität als Architekturfalle“