Angular, React und Vue in einem Produkt

Angular, React und Vue können in einem Produkt nebeneinander betrieben werden. Sinnvoll ist das nur, wenn sie technisch getrennte Anwendungen bleiben und der organisatorische Nutzen die dauerhaften Kosten einer polyglotten Frontend-Plattform rechtfertigt.

Die Frameworks müssen nicht miteinander können. Sie müssen sauber nebeneinander laufen.

Damit ist mehr gemeint als die bloße Fähigkeit, verschiedene JavaScript-Bundles in dieselbe Seite zu laden. Jedes Framework benötigt einen eigenen DOM-Bereich, einen eigenen Zustand und einen eigenen Lebenszyklus. Der Host darf wissen, wie eine Anwendung gestartet und beendet wird. Er sollte nicht wissen müssen, wie diese Anwendung intern rendert, Abhängigkeiten verwaltet oder ihren Zustand organisiert.

Framework-Autonomie ist deshalb kein kostenloser Vorteil. Sie ist eine dauerhaft zu finanzierende Plattformentscheidung.

Das gilt nicht nur für Runtimes, Build-Systeme und Know-how. Es betrifft ebenso die Oberfläche. Die Frameworks dürfen unterschiedlich sein. Das Produkt darf sich für den Nutzer trotzdem nicht wie drei Anwendungen anfühlen.

Drei Frameworks bedeuten drei Anwendungen

Ein polyglottes Frontend lässt sich am klarsten verstehen, wenn Angular, React und Vue nicht als austauschbare Komponentenmodelle betrachtet werden, sondern als eigenständige Anwendungen innerhalb eines gemeinsamen Produkts.

Angular Host
├── Angular-Bereich
│   └── Angular Root
├── React-Bereich
│   └── React Root
└── Vue-Bereich
    └── Vue Root

Jeder dieser Bereiche besitzt seine eigene Runtime, seinen eigenen Komponentenbaum, seinen eigenen Renderingmechanismus und seinen eigenen lokalen Zustand. Er wird separat gestartet, besitzt ein eigenes Fehlerverhalten und muss beim Entfernen zuverlässig aufgeräumt werden.

Angular verwaltet seine Komponenten nach den Regeln von Angular. React besitzt einen eigenen Root und kontrolliert den darunterliegenden DOM-Bereich. Vue bringt ebenfalls sein eigenes Komponenten- und Reaktivitätsmodell mit. Für die Integration ist nicht entscheidend, wie ähnlich oder unterschiedlich diese Modelle im Detail sind.

Entscheidend ist, wem welcher Bereich gehört.

Polyglotte Frontends funktionieren nicht durch eine gemeinsame Framework-Abstraktion, sondern durch klare technische Eigentumsgrenzen. Der Versuch, die internen Modelle mehrerer Frameworks zu vereinigen, beseitigt ihre Unterschiede nicht. Er verteilt sie lediglich über eine schwer verständliche Integrationsschicht.

Eigener DOM-Bereich, eigener Zustand, eigener Lebenszyklus

Der Host stellt einem Remote einen Container bereit. Sobald das Remote dort eingehängt wurde, gehört der darunterliegende Bereich vollständig dem jeweiligen Framework.

Angular Host
│
├── Angular Root
│   └── nur Angular verwaltet diesen Bereich
│
├── React Mount Point
│   └── nur React verwaltet diesen Bereich
│
└── Vue Mount Point
    └── nur Vue verwaltet diesen Bereich

Ein Angular-Host darf einen Container für eine React-Anwendung erzeugen und diesen Container später wieder entfernen. Er sollte aber nicht innerhalb des React-Roots DOM-Elemente verändern. Ebenso sollte eine React-Komponente weder auf den Angular-Injector zugreifen noch Angular-Komponenteninstanzen kontrollieren.

Auch Zustandsmodelle gehören nicht über diese Grenze. Ein Angular-Service wird nicht zum React-Context. Ein React-Store wird nicht direkt aus einer Angular-Komponente verändert. Ein Vue-Store wird nicht zum gemeinsamen Zustand aller beteiligten Anwendungen.

Solche Verbindungen wirken anfangs oft pragmatisch. Das benötigte Objekt ist bereits vorhanden, beide Anwendungen laufen ohnehin im selben Browser und eine direkte Referenz spart scheinbar einen zusätzlichen Vertrag. Tatsächlich entsteht damit eine technische Abhängigkeit von internen Framework- und Anwendungsdetails.

Das Problem zeigt sich spätestens bei Updates, Tests und Fehlern. Ein Team kann seine interne Implementierung nicht mehr ändern, ohne die fremde Anwendung zu berücksichtigen. Lebenszyklen werden voneinander abhängig. Cleanup wird unklar. Tests müssen mehrere Frameworks gleichzeitig aufbauen, obwohl sie eigentlich nur einen Bereich prüfen sollen.

Ein Framework darf den DOM-Bereich eines anderen Frameworks einhängen und entfernen. Es darf ihn nicht intern verwalten.

Der Integrationsvertrag kennt Start und Ende

Die Integration benötigt keinen gemeinsamen Komponentenstandard. Häufig genügt ein kleiner, frameworkneutraler Lifecycle-Vertrag.

interface RemoteApplication {
  mount(container: HTMLElement, context: PlatformContext): void;
  unmount(): void;
}

Der Host kennt damit den Container, den Startpunkt und das erforderliche Cleanup. Zusätzlich kann er einen kleinen Plattformkontext übergeben und Lade- oder Fehlerzustände darstellen.

Er kennt dagegen keine React-Komponenten, Hooks oder Context-Objekte. Er kennt keine Angular-Injektoren und keine Vue-Komponenteninstanzen. Er muss auch nicht wissen, wie das Remote seinen Zustand speichert oder wann es intern neu rendert.

Der Host kennt, wie die Anwendung gestartet und beendet wird. Er kennt nicht, wie sie intern funktioniert.

Der Vertrag kann je nach Plattform asynchron sein, einen Fehlerzustand zurückgeben oder weitere Lifecycle-Operationen enthalten. Diese technischen Varianten ändern nichts am eigentlichen Prinzip: Die Grenze beschreibt die Integration einer Anwendung und nicht die Fernsteuerung ihrer Komponenten.

Je kleiner dieser Vertrag bleibt, desto unabhängiger kann das jeweilige Framework innerhalb seines Bereichs weiterentwickelt werden.

Ein kleiner Vertrag am window-Objekt

In einem realen Projekt wurde eine React-Anwendung in einen Angular-Host integriert, indem sie einen kleinen Vertrag am globalen window-Objekt registrierte.

window.reactRemote.mount(container, context);
window.reactRemote.unmount();

Diese Lösung ist technisch grob. Das globale Objekt benötigt einen eindeutigen Namen. Der Ladezeitpunkt muss kontrolliert werden. Bootstrap-Fehler dürfen nicht unbemerkt bleiben. Der Vertrag muss versioniert werden und das Cleanup darf nicht vergessen werden. Auch Tests müssen die globale Registrierung gezielt vorbereiten und wieder entfernen.

Als allgemeine Produktions-API sollte ein unkontrolliert wachsendes window-Objekt deshalb nicht dienen.

Architektonisch kann ein solcher Vertrag trotzdem erstaunlich ehrlich sein. Angular kennt keine React-Komponenten. React kennt keine Angular-Services. Beide Frameworks besitzen getrennte Lebenszyklen. Die gemeinsame Grenze besteht lediglich aus einem DOM-Container, einem Kontext sowie mount und unmount.

Ein rustikaler, aber kleiner frameworkneutraler Vertrag kann sauberer sein als eine elegante Verflechtung beider Framework-Runtimes.

Derselbe Vertrag kann über eine kontrollierte Registry, einen Loader oder eine andere Integrationsinfrastruktur bereitgestellt werden. Die technische Bereitstellung darf verbessert werden. Die inhaltliche Grenze sollte dabei nicht durchlässiger werden.

Die Plattform teilt Verträge, nicht Framework-Interna

Die beteiligten Anwendungen benötigen meistens gemeinsame Plattformfähigkeiten. Authentifizierung, Navigation, Sprache, Theme, Telemetrie, Feature-Konfiguration und Sitzungsinformationen lassen sich nicht für jedes Remote vollständig isoliert behandeln.

Diese Fähigkeiten sollten trotzdem nicht als Angular Services, React Contexts oder Vue Stores veröffentlicht werden.

Platform Contract
├── Authentication
├── Navigation
├── Locale
├── Theme
├── Telemetry
├── Feature Configuration
└── Session Context

Ein solcher Vertrag bleibt klein, stabil und frameworkneutral. Er transportiert keine Komponenteninstanzen und keinen fachlichen Zustand anderer Remotes. Er setzt keine bestimmten Renderingzyklen voraus und kontrolliert nicht die internen Lebenszyklen der Anwendungen.

Jedes Framework kann diesen Vertrag anschließend in seine eigene Welt übersetzen.

Frameworkneutraler Plattformvertrag
├── Angular Adapter
├── React Adapter
└── Vue Adapter

Der Angular-Adapter kann die Daten in Angular-interne Mechanismen überführen. Der React-Adapter kann daraus einen Context oder passende Hooks anbieten. Der Vue-Adapter übersetzt denselben Vertrag in Vue-interne Strukturen. Diese Adapter bleiben innerhalb der jeweiligen Anwendung.

So kann jedes Team idiomatisch mit seinem Framework arbeiten, ohne die Plattform an eines dieser Frameworks zu binden.

Eine polyglotte Frontend-Plattform spart keine Standardisierung. Sie verschiebt sie von den Frameworks auf die Integrationsverträge.

Framework-Trennung ist keine Browser-Sandbox

Getrennte Roots schaffen technische Eigentumsgrenzen. Sie erzeugen aber keine vollständige Isolation.

Alle Anwendungen befinden sich weiterhin im selben window und im selben document. Sie teilen sich die Browser-History und den Main Thread der Seite. Netzwerk-, Speicher- und CPU-Ressourcen werden weiterhin innerhalb derselben Browserumgebung beansprucht.

Damit bleiben zahlreiche Konfliktflächen bestehen:

• globale Styles und CSS Custom Properties
• Router und History
• Overlays oder Portals unterhalb von body
• globale Event Listener und Error Handler
• Storage-Schlüssel
• Telemetrie
• Custom-Element-Registrierungen
• Netzwerk- und Main-Thread-Auslastung

Ein rechenintensiver React-Bereich kann weiterhin den Angular-Host blockieren. Ein globales Stylesheet aus einem Vue-Remote kann Selektoren außerhalb seines eigentlichen Bereichs beeinflussen. Ein Dialog oder Tooltip kann über ein Portal an einer Stelle im DOM erscheinen, die nicht mehr innerhalb des vorgesehenen Roots liegt.

Framework-Trennung ist keine Browser-Sandbox.

Diese Einschränkung spricht nicht gegen getrennte Roots. Sie beschreibt lediglich, welche Verantwortung trotz sauberer Frameworkgrenzen bei der gemeinsamen Plattform verbleibt.

Shadow DOM kapselt nur einen Teil des Problems

Shadow DOM kann unabhängig vom verwendeten Framework als zusätzliche Integrationsgrenze eingesetzt werden.

Framework Mount Point
└── optionaler Shadow Root
    └── Framework Root

Damit lässt sich die lokale CSS-Kaskade besser kontrollieren. Globale Selektoren erreichen den gekapselten Bereich nicht ohne Weiteres und der DOM-Besitz wird sichtbarer. Einige Namens- und Stylekonflikte können dadurch vermieden werden.

React verwendet jedoch nicht grundsätzlich Shadow DOM. Auch Angular- oder Vue-Anwendungen werden durch ihre bloße Existenz nicht automatisch in einen Shadow Root verschoben.

Vor allem erzeugt Shadow DOM keinen eigenen JavaScript-Realm. Main Thread, Speicher, Netzwerk, window, Storage und Framework-Runtimes bleiben gemeinsam. Auch die organisatorischen Wartungskosten verschwinden nicht.

Gleichzeitig entstehen neue Integrationsfragen. Portals und Overlays müssen mit der Grenze umgehen. Fokusverhalten, Formulare, Accessibility und Ereignisgrenzen benötigen besondere Aufmerksamkeit. Globale Schriftarten, CSS Custom Properties und Design Tokens müssen an der Grenze bewusst definiert und auf ihre Vererbung geprüft werden. Nicht jedes Testwerkzeug versteht die zusätzliche Kapselung ohne weitere Konfiguration.

Shadow DOM kann DOM und Styles stärker kapseln. Es verwandelt einen Frameworkbereich nicht in eine eigene Anwendung oder einen eigenen Browserkontext.

Drei Frameworks erzeugen dauerhafte Plattformkosten

Die technische Machbarkeit ist selten das eigentliche Problem. Angular, React und Vue lassen sich starten. Schwieriger ist es, sie über Jahre zuverlässig zu betreiben.

Jedes zusätzliche Framework bringt eine eigene Runtime, ein eigenes Ökosystem und eigene Entwicklungsmodelle mit.

Angular
├── Runtime
├── Updates
├── Build
├── Testing
├── Debugging
└── Know-how

React
├── Runtime
├── Updates
├── Build
├── Testing
├── Debugging
└── Know-how

Vue
├── Runtime
├── Updates
├── Build
├── Testing
├── Debugging
└── Know-how

Zur Laufzeit können zusätzliche Downloads, mehrfaches Bootstrap, weiterer Speicherverbrauch und zusätzliche Main-Thread-Arbeit entstehen. Wie stark diese Kosten ausfallen, hängt von der konkreten Anwendung und ihrer Auslieferung ab. Kostenlos sind weitere Runtimes trotzdem nicht.

Größer sind häufig die langfristigen Plattformkosten. Die Organisation benötigt Kompetenz für alle unterstützten Frameworks. Sie muss Updates und Sicherheitskorrekturen in mehreren Ökosystemen planen. Build-, Test- und Debugging-Probleme unterscheiden sich. Monitoring und Fehleranalyse müssen alle Anwendungen erfassen, obwohl sie technisch verschieden arbeiten.

Hinzu kommen Plattform-Adapter, Dokumentation, Onboarding und gemeinsame Qualitätsregeln. Bei einem Incident muss jemand nicht nur den fachlichen Bereich, sondern auch dessen Framework und Toolchain beherrschen.

Die entscheidende Frage lautet deshalb nicht, ob ein Team das dritte Framework heute produktiv einsetzen kann.

Die entscheidende Frage lautet: Wer betreibt das dritte Framework in fünf Jahren?

Vielleicht haben die ursprünglichen Entwickler das Unternehmen dann verlassen. Vielleicht hat sich das Ökosystem verändert. Vielleicht ist der Bereich fachlich stabil und erhält nur noch gelegentliche Wartung. Gerade dann muss weiterhin jemand Sicherheitsupdates durchführen, Builds reparieren und Fehler analysieren können.

Ein zusätzliches Framework ist keine lokale Projektentscheidung, wenn es dauerhaft Teil desselben Produkts und derselben Plattform wird.

Das Produkt muss sich trotzdem einheitlich anfühlen

Framework-Autonomie wird häufig als Möglichkeit verstanden, technische Vorgaben zu reduzieren. Jedes Team kann etablierte Werkzeuge seines Ökosystems verwenden und innerhalb seines Bereichs unabhängig entscheiden.

Für Nutzer existieren diese technischen Grenzen jedoch nicht. Sie bewegen sich durch ein gemeinsames Produkt.

Farben, Typografie und Abstände dürfen nicht bei jedem Wechsel des Remotes sichtbar springen. Eingabefelder sollten sich vergleichbar verhalten. Validierung, Fokuszustände, Tastaturinteraktion, Dialoge, Ladeanzeigen und Fehlermeldungen müssen einer gemeinsamen Logik folgen.

Das betrifft ebenso responsive Regeln, Tabellen, Overlays, leere Zustände und riskante oder irreversible Aktionen. Accessibility darf nicht davon abhängen, welches Framework gerade einen Bereich rendert.

Was durch lokale Frameworkflexibilität eingespart wird, kann als dauerhafte UI- und UX-Harmonisierung zurückkehren.

Die Frameworks dürfen technisch verschieden sein. Für Nutzer darf der Wechsel zwischen ihnen nicht wie ein Wechsel zwischen unabhängigen Produkten wirken.

„Beide verwenden Material“ reicht nicht

Angular Material und Material UI zeigen dieses Problem besonders anschaulich.

Angular
└── Angular Material

React
└── Material UI

Beide Bibliotheken orientieren sich an einer ähnlichen Designsprache. Daraus folgt jedoch nicht, dass ihre Komponenten im selben Produkt automatisch identisch wirken oder sich gleich verhalten.

Es handelt sich um eigenständige Bibliotheken mit eigenen APIs, Defaultwerten, Theme-Systemen, Komponentenstrukturen und Releasezyklen. Auch Accessibility-Entscheidungen und Interaktionsdetails werden jeweils innerhalb der eigenen Bibliothek getroffen.

Unterschiede können bei der Höhe und Dichte von Eingabefeldern beginnen. Sie zeigen sich in Abständen, Typografie, Hover- und Fokuszuständen, Disabled-Darstellungen oder Animationen. Label-Verhalten, Fehlermeldungen, Dialoge, Tabellen, Menüs und Autocomplete-Komponenten können sich in kleinen, aber sichtbaren Details unterscheiden.

Auf getrennten Demo-Seiten wirken beide Bibliotheken jeweils konsistent. Direkt nebeneinander in einem Produkt werden Abweichungen schneller sichtbar.

Das ist kein Qualitätsvergleich. Keine der beiden Bibliotheken muss die andere exakt nachbilden. Das Problem entsteht erst durch die Erwartung, eine ähnliche Designherkunft ersetze ein gemeinsames Produktdesign.

„Beide verwenden Material“ ist noch kein gemeinsames Design-System.

Das Design-System liegt oberhalb der Frameworks

Ein Angular-Host kann sein Angular-Material-Theme nicht einfach zum Produktvertrag erklären. React- oder Vue-Anwendungen können mit Angular-spezifischen Theme-Objekten, Sass-Strukturen oder Komponenten-APIs nichts anfangen.

Das gemeinsame Modell muss oberhalb der Frameworks liegen.

Produkt-Design-System
├── Farben
├── Typografie
├── Abstände
├── Radien
├── Schatten
├── Dichte
├── Breakpoints
├── Motion
├── Fokusregeln
├── Validierungsregeln
└── Interaktionsmuster

Aus diesem Produktmodell entstehen frameworkbezogene Umsetzungen.

Globale Design Tokens und UX-Regeln
├── Angular-Material-Theme
├── Material-UI-Theme
└── Vue-Theme

Die gemeinsame Quelle kann Design Tokens, CSS Custom Properties, Dokumentation und verbindliche UX-Regeln enthalten. Welches technische Format dafür verwendet wird, ist weniger wichtig als die Richtung der Abhängigkeit.

Das Produkt definiert die Regeln. Die Frameworks übersetzen sie in ihre jeweiligen Komponentenwelten.

Das Produkt besitzt ein Design-System. Die Frameworks besitzen lediglich Adapter dafür.

Diese Adapter sind kein einmaliges Setup. Sie müssen bei Updates der Komponentenbibliotheken weiterentwickelt werden. Neue Komponenten benötigen eine Einordnung. Abweichende Defaults müssen erkannt und gegebenenfalls angepasst werden. Visuelle Regressionen und Accessibility bleiben gemeinsame Verantwortung.

Farben allein erzeugen keine UX-Konsistenz

Ein Satz globaler Variablen kann wichtige Grundlagen vereinheitlichen.

--color-primary: ...;
--surface-default: ...;
--spacing-medium: ...;
--border-radius: ...;

Damit lassen sich Farben, Abstände oder Radien in mehreren Frameworks konsistent verwenden. Ein gemeinsames Produkterlebnis entsteht daraus noch nicht.

Tokens beantworten nicht, wie hoch ein Standard-Eingabefeld sein soll oder wann Validierungsfehler sichtbar werden. Sie definieren nicht, wie Pflichtfelder markiert werden und wohin der Fokus nach dem Schließen eines Dialogs zurückkehrt.

Sie legen nicht fest, wie eine Combobox per Tastatur bedient wird, welche Fehler eine Aktion blockieren oder wie Ladezustände aussehen. Ebenso wenig bestimmen sie die Dichte einer Tabelle, die Position von Tooltips oder die Bestätigung einer riskanten oder irreversiblen Aktion.

Visuelle Konsistenz entsteht aus gemeinsamen Grundlagen. UX-Konsistenz benötigt zusätzlich gemeinsame Verhaltensregeln.

Ein gemeinsames Theme ist deshalb kein Stylesheet, sondern ein Produktvertrag, der für jedes Framework umgesetzt und dauerhaft gepflegt werden muss.

Nicht für jedes Framework eine eigene Komponentenwelt bauen

Die sichtbaren Unterschiede mehrerer Komponentenbibliotheken lassen sich theoretisch durch eigene UI-Kits beseitigen.

eigenes Angular UI Kit
+
eigenes React UI Kit
+
eigenes Vue UI Kit

Damit betreibt die Organisation allerdings nicht eine gemeinsame Komponentenbibliothek, sondern mehrere eigene Komponentenplattformen.

Für jede Umsetzung entstehen Accessibility-Verantwortung, Tests, Dokumentation, Fehlerbehebung und Updates. Komplexe Komponenten wie Comboboxen, Tabellen, Datumsauswahlen oder Dialoge müssen mehrfach entwickelt und über Jahre vergleichbar gehalten werden. Jede neue Produktanforderung erzeugt Paritätsarbeit zwischen den Frameworks.

Eine eigene Komponentenwelt kann für besonders markenprägende oder fachlich kritische Elemente sinnvoll sein. Sie sollte aber nicht die automatische Antwort auf jede kleine Abweichung etablierter Bibliotheken werden.

Pragmatischer ist es meist, pro Framework eine etablierte Komponentenbibliothek einzusetzen, darüber ein frameworkneutrales Design-System zu definieren und die Bibliotheken so weit wie sinnvoll zu konfigurieren. Kleine Unterschiede dürfen bewusst akzeptiert werden, solange das Produkt zusammengehörig und vorhersehbar bleibt.

Das Ziel ist nicht absolute Pixelidentität. Das Ziel ist ein konsistentes Verhalten und eine gemeinsame Produktsprache.

Pixelgenaue Parität zwischen unterschiedlichen Komponentenbibliotheken kann teurer werden als die ursprüngliche Frameworkfreiheit.

Wann mehrere Frameworks sinnvoll sein können

Die zusätzlichen Kosten bedeuten nicht, dass polyglotte Frontends grundsätzlich falsch sind.

Ein bestehendes Produkt kann einen anderen Stack mitbringen und schrittweise in eine neue Plattform integriert werden. Ein zugekauftes System lässt sich möglicherweise wirtschaftlicher weiterbetreiben als vollständig neu entwickeln. Eine fachlich eigenständige Capability kann bereits mit einem etablierten Team und langfristig verfügbarem Know-how existieren.

Auch besondere technische Anforderungen können einen anderen Stack rechtfertigen. Ebenso kann ein klar begrenztes Experiment sinnvoll sein, wenn Ziel, Owner und Auswertung feststehen. Voraussetzung ist jeweils, dass die Plattform ausdrücklich auf den zusätzlichen Stack vorbereitet wird.

Starke und stabile organisatorische Grenzen erleichtern diese Entscheidung. Ein eigenständiger Bereich mit langfristigem Ownership kann die Verantwortung für seinen Stack tragen. Häufig wechselnde Teamzuschnitte und unklare Zuständigkeiten sprechen dagegen.

Nicht jede lokale Präferenz ist jedoch ein wirtschaftlicher Grund.

Ein Team mag React lieber als Angular. Ein anderes möchte Vue ausprobieren. Ein neues Framework kann populär wirken oder beim Recruiting attraktiv erscheinen. Eine kleine Funktion scheint mit einem anderen Stack schneller umsetzbar zu sein.

Solche Argumente betrachten vor allem den ersten Anwendungsfall. Sie beantworten nicht, wer die Integration pflegt, Sicherheitsupdates übernimmt, das Design-System adaptiert und den Bereich in mehreren Jahren betreibt.

Framework-Autonomie ist sinnvoll, wenn sie ein reales organisatorisches, fachliches oder wirtschaftliches Problem löst – nicht, wenn sie lediglich lokale Präferenzen institutionalisiert.

Wer trägt die Kosten?

Der Nutzen eines zusätzlichen Frameworks entsteht häufig lokal.

Ein Team arbeitet mit einer vertrauten Technologie, kann vorhandenes Know-how einsetzen und sein Tooling selbst bestimmen. Dadurch kann die Entwicklung in diesem Bereich schneller oder zuverlässiger werden.

Die zusätzlichen Kosten entstehen dagegen an mehreren Stellen.

Die Plattform pflegt Integrationsverträge, Framework-Adapter, Build- und Testsysteme, Observability, Sicherheitsupdates und Dokumentation. Sie muss UI und UX über mehrere Komponentenwelten hinweg harmonisieren und bei Incidents Support leisten.

Das Produkt trägt zusätzliche Runtimes, Downloads und potenzielle Inkonsistenzen. Nutzer erleben unterschiedliche Interaktionsdetails oder Accessibility-Qualität, wenn die Harmonisierung nicht zuverlässig funktioniert.

Damit kann eine Entscheidung für das lokale Team eindeutig positiv und für das Gesamtprodukt trotzdem negativ sein.

Der lokale Vorteil eines Teams ist nur dann ein Gesamtvorteil, wenn die zusätzlichen Plattform- und Produktkosten kleiner bleiben.

Diese Abwägung lässt sich nicht allein innerhalb des Teams treffen, das den neuen Stack verwenden möchte. Es profitiert unmittelbar von der Entscheidung, trägt aber nicht zwangsläufig alle langfristigen Folgen.

Ein neues Framework braucht eine Eintrittsschwelle

Für neue Bereiche sollte ein Standardframework der Normalfall bleiben. Ein gemeinsamer Standard reduziert nicht jede technische Schwierigkeit, begrenzt aber die Zahl der dauerhaft zu betreibenden Ökosysteme.

Weitere Frameworks benötigen einen konkreten fachlichen, organisatorischen oder wirtschaftlichen Grund. Dieser Grund muss stärker sein als persönliche Vorlieben oder kurzfristige Produktivität.

Wird ein zusätzliches Framework zugelassen, benötigt es klare Grenzen. Es bleibt vollständig in seinem eigenen DOM-Bereich, verwaltet seinen Zustand selbst und besitzt einen unabhängigen Lebenszyklus. Framework-Interna überschreiten die Grenze nicht.

Der Host kennt nur kleine, frameworkneutrale Lifecycle- und Plattformverträge. Authentifizierung, Navigation, Sprache, Theme und Telemetrie werden als stabile Plattformfähigkeiten bereitgestellt und innerhalb jedes Frameworks adaptiert.

Das Design-System liegt oberhalb der Frameworks. Jede unterstützte Komponentenwelt erhält einen gepflegten Theme- und UX-Adapter. Etablierte Bibliotheken bleiben der Normalfall. Eigene Komponenten werden dort entwickelt, wo der Produktnutzen ihre langfristigen Kosten rechtfertigt.

Vor allem benötigt jedes Framework dauerhaftes Ownership. Update-Strategie, Sicherheitsverantwortung, Support und Know-how müssen geklärt sein, bevor aus einem lokalen Experiment ein Bestandteil der Produktplattform wird.

Framework-Autonomie braucht eine Eintrittsschwelle. Wer ein weiteres Framework einführt, muss nicht nur dessen ersten Anwendungsfall erklären, sondern auch seinen langfristigen Betrieb.

Fazit

Angular, React und Vue können in demselben Produkt laufen, weil jedes Framework seinen eigenen Teil der Oberfläche verwaltet. Sie müssen einander nicht verstehen. Diese Trennung funktioniert jedoch nur, solange keine Framework-Interna über die Grenze getragen werden. Gemeinsam sind nicht Komponenten, Stores oder Renderingzyklen, sondern kleine, stabile Plattformverträge.

Getrennte Roots schaffen klare Eigentumsgrenzen, aber keine vollständige Browser-Sandbox. Gleichzeitig muss die Organisation mehrere Runtimes, Toolchains und Wissensgebiete dauerhaft betreiben. Der Aufwand endet nicht nach dem ersten erfolgreichen Bootstrap.

Auch das Design-System muss in mehrere Komponentenwelten übersetzt werden. Ähnliche Bibliotheken wie Angular Material und Material UI erzeugen noch keine identische UI oder UX. Visuelle Tokens benötigen verbindliche Verhaltensregeln und gepflegte Adapter, damit die technische Vielfalt für Nutzer nicht zu einem Produkt aus sichtbar unterschiedlichen Anwendungen wird.

Framework-Autonomie ist deshalb nur sinnvoll, wenn ihr konkreter Nutzen diese dauerhaften Plattformkosten rechtfertigt.

Mehrere Frameworks sind keine technische Spielerei einzelner Teams. Sie sind eine dauerhafte Investition der gesamten Plattform.