Die Antwort, die zehn Jahre lang unverändert blieb
Wenn jemand in den letzten zehn Jahren fragte, wie er ein Frontend bauen soll, war die Antwort erstaunlich stabil: nimm ein Framework. Die einzige offene Frage war welches – React, Vue, Angular, später Svelte oder Solid. Dass man überhaupt eines nimmt, stand nicht zur Debatte. Ein Framework war nicht die Wahl, es war der Ausgangspunkt, von dem aus man wählte.
Diese Selbstverständlichkeit ist kein Zufall. Frameworks haben ihre Dominanz verdient, mit handfesten Argumenten, die über ein Jahrzehnt gehalten haben. Aber genau die Rechnung, die sie gewinnen ließ, wird gerade von der KI-Codegenerierung neu aufgestellt. Wenn ein Modell in jedem beliebigen Stack in Sekunden eine ganze Oberfläche gerüstet bekommt, schrumpft der ergonomische Vorsprung, der das ganze Argument getragen hat – und die Kosten, die ein Framework immer schon mitbrachte, treten schärfer hervor. Die ehrliche Frage lautet deshalb nicht, ob das nächste Framework das letzte ablöst. Sie lautet: Endet die Ära, in der ein Schwergewichts-Framework die naheliegende Antwort war?
Warum die Frameworks gewonnen haben
Man versteht die Verschiebung nur, wenn man ernst nimmt, warum Frameworks überhaupt gewonnen haben. Es war kein Hype und keine Mode. Es waren drei sehr reale Vorteile.
Der erste war Komponenten-Wiederverwendung. Vor React baute man Oberflächen, indem man das DOM von Hand manipulierte – ein Button hier, ein Event-Handler da, und die Wahrheit über den Zustand der Seite lag verstreut in einem Dutzend Stellen, die man synchron halten musste. React hat daraus ein Modell gemacht: Zustand rein, UI raus, als Funktion. Man baut ein <DatePicker /> einmal und benutzt ihn hundertmal, und er verhält sich jedes Mal gleich. Das war ein echter Fortschritt in der Art, wie man über Interfaces denkt.
Der zweite war das Ökosystem. Ein Framework zu wählen hieß nie, nur eine Bibliothek zu wählen. Es hieß, in ein ganzes Universum einzukaufen: Router, State-Management, Formular-Bibliotheken, Komponenten-Kits, Testing-Utilities, Tausende beantwortete Stack-Overflow-Fragen. Wer sich für React entschied, entschied sich für Next.js, für eine Deployment-Story, für fertige Antworten auf Probleme, die er noch gar nicht hatte. Das Ökosystem war der eigentliche Burggraben, nicht die Bibliothek in seiner Mitte.
Der dritte, und für Firmen oft der wichtigste, war der Recruiting-Pool. React zu wählen hieß, aus einem Meer von Entwicklern schöpfen zu können, die es schon konnten. Man musste niemanden umschulen. Ein neuer Kollege war in Tagen produktiv, nicht in Monaten, weil er dieselben Muster schon dreimal woanders gesehen hatte. Für eine Organisation ist das kein Nebenaspekt – es ist die Differenz zwischen einem Team, das man skalieren kann, und einem, das an exotischem Wissen in wenigen Köpfen hängt.
Diese drei Vorteile bündelten sich in einem einzigen Verkaufsargument, das über allem stand: Developer Velocity. Ein Framework machte Teams schneller. Es nahm dir die immer gleiche Klempnerarbeit ab und ließ dich am Produkt statt an der Infrastruktur bauen. Das war das Versprechen, und es war größtenteils wahr. Genau dieses Versprechen ist es, das die KI jetzt angreift.
Was die KI an der Rechnung ändert
Der entscheidende Punkt ist unspektakulär und trotzdem folgenreich: Generierung ist billig geworden, und zwar egal in welchem Stack. Ein Modell rüstet dir eine Tabellenansicht mit Sortierung, Pagination und Ladezuständen in React genauso in Sekunden zusammen wie in Vue oder in reinem HTML mit ein paar Event-Handlern. Der Aufwand, eine Oberfläche zum ersten Mal hinzustellen, ist für den Menschen in allen Stacks ungefähr gleich gegen null gefallen.
Damit passiert etwas mit dem Hauptargument des Frameworks. Wenn „Developer Velocity" bedeutete, dass dir das Framework die schnelle erste Version schenkt – dann schenkt dir das jetzt das Modell, in jedem Stack. Die Geschwindigkeit, die früher der Vorsprung des Frameworks war, ist kein Alleinstellungsmerkmal mehr. Sie ist zur Grundausstattung geworden, die überall verfügbar ist. Der ergonomische Abstand zwischen „mit Framework" und „ohne Framework" schrumpft genau in dem Moment, in dem nicht mehr der Mensch die erste Version tippt.
Und sobald die Geschwindigkeit beim Schreiben nivelliert ist, treten die Kosten hervor, die das Framework immer schon hatte und die man bereit war zu zahlen, weil die Geschwindigkeit sie aufwog. Die Bundle-Größe. Die Build-Pipeline mit ihren fünf Werkzeugen. Die Abhängigkeitsbäume mit ihren tausend transitiven Paketen. Und vor allem der Churn – die Ermüdung dessen, der über die Jahre von Klassen-Komponenten zu Hooks zu Server-Komponenten migriert ist, von Webpack zu Vite, von einem Datenlade-Paradigma zum nächsten. Jede dieser Migrationen kostete Wochen und lieferte dem Nutzer der Seite: nichts. Solange das Framework dich schneller machte, hast du diese Rechnung akzeptiert. Wenn die Geschwindigkeit überall gleich ist, fällt die Gegenseite der Rechnung weiter ins Gewicht.
Hier kommt allerdings eine Verdrehung ins Spiel, die man nicht übersehen darf. Modelle sind nicht in allen Stacks gleich gut. Sie sind am besten in dem, was am häufigsten im Trainingsmaterial vorkommt – und das ist mit großem Abstand React und Next.js. Ein Modell schreibt zuverlässigeres React als Svelte, schlicht weil es tausendmal mehr React gesehen hat. Das erzeugt ein Verfestigungs-Paradox: Dasselbe KI-Werkzeug, das theoretisch jeden Stack gleich billig macht, macht in der Praxis den ohnehin dominanten Stack noch attraktiver. Wer sich vom Modell helfen lässt, wird sanft, aber stetig genau dorthin geschoben, wo schon alle sind. Die KI demokratisiert die Stack-Wahl nicht – sie zentralisiert sie.
Der Gegentrend: kleiner, standardnäher, langweiliger
Parallel dazu, und nicht zufällig, gewinnt eine Gegenbewegung an Boden, die vom Framework wegzeigt – zurück zur Plattform selbst.
Da sind die Web Components: Komponenten als Web-Standard, direkt im Browser, ohne Framework darunter. Custom Elements und Shadow DOM liefern die Kapselung, die früher der Grund war, ein Framework mitzuschleppen – nur eben eingebaut und ohne Verfallsdatum. Da ist HTMX, das die Prämisse der Single-Page-App schlicht umkehrt: Statt JSON zu holen und im Client zu rendern, schickt der Server fertiges HTML, und ein paar Attribute im Markup tauschen die richtigen Fragmente aus. Für einen ganzen Streifen von Anwendungen – Formulare, Listen, Dashboards, CRUD – ist das nicht weniger fähig, sondern radikal weniger kompliziert. Da ist die HTML-first-Haltung generell und die Formel „Vanilla plus ein bisschen": moderne Browser können heute vieles nativ, wofür man früher ein Paket zog, und die Lücke füllt man mit ein paar Zeilen statt mit einem Ökosystem.
Was diese Ansätze eint, ist nicht Nostalgie. Es ist die Beobachtung, dass ein großer Teil dessen, wofür wir Frameworks angeschafft haben, entweder in die Plattform gewandert oder von der KI billig geworden ist. Der Churn des JS-Ökosystems – dieses Gefühl, dass das, was du letztes Jahr gelernt hast, dieses Jahr schon wieder das Falsche ist – hat einen Preis, den mehr Teams offen als Verlust verbuchen. Und ein Standard veraltet nicht auf dieselbe Weise: HTML von 2015 rendert 2026 noch. Ein Frontend-Toolchain von 2015 ist Archäologie.
Die eigentliche Frage hat sich verschoben
Wenn man diese Fäden zusammenzieht, ändert sich weniger die Antwort als die Frage. Ein Jahrzehnt lang lautete sie: „Welches Framework?" Man wählte zwischen React, Vue und Angular, und die Wahl definierte alles Weitere.
Die Frage, die heute zählt, ist eine andere: „Was ist das Kleinste, das ausliefert und wartbar bleibt?" Das ist keine rhetorische Verkleinerung, sondern ein anderer Startpunkt. Für ein Marketing-Portfolio mit drei interaktiven Elementen ist die ehrliche Antwort vielleicht HTML mit einer Prise JavaScript – und ein Modell schreibt dir das genauso gern wie eine React-App, nur dass hinterher keine Build-Pipeline zu warten ist. Für eine hochinteraktive Anwendung mit komplexem geteiltem Zustand ist die ehrliche Antwort vielleicht weiterhin React – nicht aus Gewohnheit, sondern weil das Problem die Maschinerie tatsächlich rechtfertigt. Der Punkt ist, dass das Framework von der Default-Annahme zu einer begründungspflichtigen Entscheidung wird. Man nimmt es nicht mehr, weil man immer eines nimmt. Man nimmt es, wenn die Aufgabe es verdient.
Nur damit wir ehrlich bleiben: Die Frameworks sterben nicht
Und jetzt der Teil, den man nicht überspringen darf, weil sonst die falsche Lehre hängen bleibt. Nichts am oben Gesagten heißt, dass React & Co. verschwinden. Im Gegenteil – mehrere der beschriebenen Kräfte wirken genau andersherum, und die ehrlichste Analyse muss das benennen.
Die Trainingsdaten-Verfestigung, die ich als Paradox eingeführt habe, ist der stärkste Grund, warum die etablierten Frameworks klebriger werden, nicht loser. Ein Modell produziert in einem populären, breit vertretenen Framework den mit Abstand zuverlässigsten Code. Es kennt die Idiome, die Fallstricke, die typischen Fehler und ihre Lösungen, weil es Millionen Beispiele gesehen hat. In einem obskuren oder ganz neuen Stack halluziniert es häufiger APIs, greift zu veralteten Mustern und produziert Code, der plausibel aussieht und subtil bricht. Wer heute einen exotischen Stack wählt mit der Begründung „ist egal, die KI kann eh alles", trifft eine Wette gegen genau das Werkzeug, mit dem er arbeiten will. Diese Wette geht öfter nach hinten los, als die Erzählung von der grenzenlosen KI vermuten lässt.
Dazu kommt: Die drei ursprünglichen Vorteile sind nicht weg. Der Recruiting-Pool von React ist immer noch riesig. Das Ökosystem ist immer noch tief. Und die Komponenten-Wiederverwendung löst immer noch ein echtes Problem, das kein noch so schneller Generator wegzaubert – nämlich Konsistenz über eine große, langlebige Codebasis hinweg. Ein Modell kann dir zehnmal einen Button generieren; ob es zehnmal denselben Button generiert, ist eine andere Sache. Genau dafür wurde das Komponentenmodell erfunden.
Der pragmatische Zug ist deshalb oft das Gegenteil von Rebellion. Er heißt: sich auf den gut unterstützten Mainstream zu lehnen – weil das Modell dort am zuverlässigsten ist, weil du Menschen findest, die es warten können, weil in fünf Jahren immer noch jemand versteht, was da steht. „Das Framework stirbt" ist eine griffige Schlagzeile. „Das Framework ist nicht mehr die reflexhafte Default-Antwort, aber in vielen Fällen weiterhin die richtige" ist die wahre, unbequemere Version.
Fazit
Die Ära, in der „nimm ein Framework" die vollständige Antwort war, geht zu Ende – aber nicht, weil die Frameworks sterben. Sie geht zu Ende, weil die Frage sich geändert hat. Solange der Mensch die erste Version tippte, war Developer Velocity das entscheidende Argument, und das Framework lieferte sie. Jetzt liefert die Generierung sie in jedem Stack, und was übrig bleibt, sind die alten Kosten – Komplexität, Churn, Bundle-Gewicht – auf der einen und die neue Verfestigung des Mainstreams auf der anderen Seite. Beides zieht in entgegengesetzte Richtungen, und genau deshalb gibt es keine pauschale Antwort mehr, nur noch eine bessere Frage: Was ist das Kleinste, das ausliefert und wartbar bleibt?
Genau so treffen wir bei NH Labs die Entscheidung. Wir wählen einen Stack nicht, weil er auf einer Konferenz gefeiert wurde, und wir werfen React nicht über Bord, weil ein Blog behauptet, es sei tot. Wir wägen zwei Dinge gegeneinander ab: Wie wartbar ist das über Jahre – und wie zuverlässig unterstützen die Modelle, mit denen wir bauen, genau diesen Stack? Manchmal ist die Antwort HTML mit einer Prise JavaScript und keiner Build-Pipeline. Manchmal ist sie React, weil das Problem es verdient und weil die Werkzeuge es am besten beherrschen. Was sie nie ist, ist eine reflexhafte Default-Wahl nach dem letzten Hype. Deshalb können unsere Kunden darauf bauen, dass das, was wir ausliefern, nicht nur heute läuft, sondern auch in fünf Jahren noch jemand versteht und ändern kann.