Um 2010 wurde klar, dass der Browser zur zentralen Laufzeitumgebung für Business-Anwendungen werden würde. Gleichzeitig zeigte sich, dass Tools wie jQuery für komplexe, wartbare Enterprise-Systeme nicht ausreichen. Es entstand eine neue Generation von Frameworks. AngularJS setzte auf Struktur und Konventionen, React auf einen konsequent funktionalen Ansatz mit unidirektionalem Datenfluss.
Die entscheidende Frage in Großprojekten war und ist jedoch selten nur, welches Framework gewählt wird, sondern vor allem wer die Auswahl trifft – und mit welcher Motivation.
Die trügerische Sicherheit großer Namen
In vielen Unternehmen wird die Framework-Wahl nicht von den Architekten getroffen, die das System am Ende verantworten müssen. Sie landet oft bei IT-Managern und Entscheidern. Deren primärer Treiber ist selten die technische Exzellenz, sondern Risikominimierung und Ressourcenplanung. Das alte Mantra „Nobody gets fired for buying IBM“ gilt heute für Namen wie Google, Microsoft oder Vercel.
Entscheidungen fallen oft nach der Logik: „Wenn wir den Marktstandard nehmen, finden wir leichter Dienstleister und Entwickler.“ Langfristige Wartbarkeit, funktionale Komposition oder die tatsächliche Passgenauigkeit für die eigene Domäne treten in den Hintergrund. Bekanntheit erzeugt ein trügerisches Gefühl von Sicherheit. Die Konsequenzen dieses Ansatzes zeigen sich meist erst Jahre später, wenn die initialen Teams längst abgezogen sind.
Angular 2 als warnendes Beispiel
Google kündigte 2014 eine komplette Neuentwicklung von Angular an. Die finale Version erschien erst 2016. In der Zwischenzeit starteten zahlreiche Enterprise-Projekte bereits auf unsicheren Release-Candidate-Versionen, getrieben von dem Versprechen des „Google-Standards“. Besonders problematisch war die späte Einführung von NgModule, die viele Teams zwang, ihre Architektur fundamental umzubauen – obwohl man sich budgetär eigentlich schon in der Stabilisierungsphase wähnte.
Für einige riesige, extrem gut strukturierte Projekte funktionierte Angular 2. Für viele andere wurde es zur Kostenfalle: zu komplex, zu viele proprietäre Konzepte und ein massiver Onboarding-Aufwand. Die Ironie dabei: Ein Teil der Skalierungsprobleme, die Angular lösen sollte, wurde durch die politisch motivierte, voreilige Einführung selbst mitverursacht.
Das eigentliche Problem sitzt tiefer
Die teuersten Enterprise-Projekte scheitern nicht am Framework selbst. Sie scheitern daran, dass die falschen Metriken die Architektur diktieren – und dass niemand die Autorität hat, Fehlentwicklungen konsequent zu korrigieren.
Typische Muster in Konzernstrukturen sind:
Recruiting vor Architektur: Es wird ein Framework gewählt, weil der Markt gerade viele (durchschnittliche) Entwickler dafür bietet, nicht weil es das beste Werkzeug für die Anforderungen ist.
Verschleppte Refactorings: Technische Schulden werden aus Termin- oder Politikgründen aufgeschoben, bis sie strukturell kaum noch lösbar sind.
Zahnlose Verantwortung: Die Zuständigkeit für technische Nachhaltigkeit liegt bei Architekten, die aber keine echte Budget- oder Entscheidungsbefugnis gegenüber dem Business haben.
Agilitäts-Theater: Agilität wird mit „schnell Features liefern“ verwechselt, während die funktionale Basis unter dem Sprint-Druck zerbröselt.
Sobald ein Projekt läuft und das Business neue Anforderungen stellt, wird es politisch extrem schwierig, fundamentale Architekturfehler zu beheben. Die technische Schuld wächst exponentiell. Je länger gewartet wird, desto höher fällt die Rechnung aus.
Die Framework-Wars sind nicht vorbei
Wer glaubt, die Zeiten der großen Framework-Debatten seien vorbei, muss sich nur die aktuelle Architektur-Diskussion im Jahr 2026 zwischen Next.js und TanStack Start ansehen. Die Argumentationslinien ähneln auf erstaunliche Weise denen von vor zehn Jahren.
Next.js hat sich als De-facto-Standard für viele React-Anwendungen etabliert. Es liefert eine extrem starke Developer Experience, erkauft diese aber durch viel „Magie“, tiefe Konventionen und eine klare Plattform-Strategie: Wer Next.js wählt, optimiert stark für die Vercel-Infrastruktur. Für das Enterprise-Umfeld bedeutet das nicht selten einen schleichenden Vendor Lock-in.
Dem gegenüber steht TanStack Start. Statt Blackbox-Automatisierung priorisiert es explizite Kontrolle und eine konsequente, typsichere Architektur. Der entscheidende Business-Faktor ist hier jedoch ein anderer: Investitionsschutz und Deployment-Freiheit. Durch den Verzicht auf tiefgreifende proprietäre Konventionen bleibt die Architektur agnostisch. Anwendungen lassen sich problemlos und kosteneffizient auf modernen Edge-Infrastrukturen wie Cloudflare Workers oder R2 betreiben.
Beide Ansätze haben ihre Berechtigung. Das Problem ist, dass auch 2026 die Wahl wieder oft nach Sichtbarkeit und dem trügerischen Gefühl „das ist gerade der Standard“ getroffen wird – anstatt strategisch zu bewerten, ob das Unternehmen Skalierbarkeit durch funktionale Komposition (TanStack) oder schnelle Time-to-Market durch Plattformbindung (Next.js) benötigt.
Was sich ändern muss
Technische Entscheidungen mit langfristiger Wirkung dürfen nicht primär nach Marketing, kurzfristiger Ressourcenverfügbarkeit oder internen Machtverhältnissen getroffen werden. Sie erfordern strategische Weitsicht und die Bereitschaft, dem Business unbequeme Wahrheiten zu präsentieren.
Konkret bedeutet das für das Enterprise-Umfeld:
Kosten der Architektur transparent machen: Wer sich für den bequemen „Standard-Weg“ entscheidet, muss auch die langfristigen Kosten für Lock-in und Infrastruktur budgetär verantworten. Technische Schulden müssen in Euro beziffert werden.
Echte architektonische Befugnisse: Strategische Technologieentscheidungen müssen von Personen mit realer Projekterfahrung freigegeben werden. Architekten brauchen ein Veto-Recht, das vom Management respektiert wird.
Unabhängige Evaluierung: Größere Projekte benötigen vor dem Start einen neutralen Proof of Concept, der die spezifischen Domänen-Anforderungen validiert – unabhängig von den bunten Landingpages der Framework-Anbieter.
Solange Unternehmen diese strukturellen Grundlagen nicht schaffen, werden sie weiterhin teure, von Halbwissen getriebene Technologieentscheidungen treffen – und Jahre später die Rechnung dafür bekommen.