React, Vue, Angular, Svelte, Solid, Qwik, Astro, Lit: Wer die Frontend-Entwicklung verfolgt, kennt das Stöhnen über die „Framework-Müdigkeit“. Jedes Jahr kommt ein neuer Name dazu, jede Konferenz hat einen neuen Favoriten, und Teams fragen sich, ob ihre Entscheidung von vor drei Jahren schon wieder veraltet ist.

Die Klage trifft aber den falschen Punkt. Die Zahl der Frameworks ist nicht das Problem. Auffällig ist vielmehr, wie ähnlich die meisten von ihnen gebaut sind. Fast alle beschreiben die Oberfläche als Baum von Komponenten, übersetzen eine eigene Template-Syntax in JavaScript und halten die Anzeige zur Laufzeit mit dem Zustand synchron. Die Unterschiede liegen in Details, die in Benchmarks und Diskussionen groß wirken. Dieser Beitrag fragt, welche Grundmodelle es tatsächlich gibt, wo die heutigen Frameworks Kosten verursachen, die man selten sieht, und wo sich gerade echte Alternativen herausbilden.

Ein Verarbeitungsmodell unter vielen Namen

Seit React 2013 erschien, folgt der Großteil der Frontend-Frameworks demselben Ablauf:

1. Die Oberfläche wird deklarativ beschrieben, also als gewünschter Endzustand statt als Folge von Befehlen – in JSX, in Vue-Templates, in Angular-Templates oder in Svelte-Dateien.
2. Ein Compiler übersetzt diese Beschreibung beim Build in JavaScript.
3. Der Browser lädt den Code und baut daraus die Seite auf.
4. Ein Laufzeitsystem beobachtet den Zustand und aktualisiert das DOM, die Baumstruktur der Seite, wenn sich etwas ändert.

Ein einfaches Beispiel in Vue:

<script setup lang="ts">
import { ref } from 'vue';

const showElement = ref(true);
const message = ref('Bestellung gespeichert');
</script>

<template>
  <div v-if="showElement">{{ message }}</div>
</template>

Zwischen diesem Code und dem sichtbaren Hinweis im Browser liegen mehrere Schritte. Der Vue-Compiler zerlegt das Template beim Build in einen Syntaxbaum, wandelt v-if in eine Bedingung und die doppelten geschweiften Klammern in einen reaktiven Ausdruck um und erzeugt daraus eine Render-Funktion. Zur Laufzeit liest diese Funktion die Werte über Vues Reaktivitätssystem, das jeden Zugriff registriert, und das Ergebnis wird mit dem vorherigen verglichen, bevor das DOM sich ändert.

Diese Kette ist kein Konstruktionsfehler. Das Parsen passiert einmal beim Build, nicht bei jedem Aufruf, und die Laufzeitkosten sind für eine Bedingung vernachlässigbar. Der Preis liegt woanders: Zwischen dem, was Entwickler:innen schreiben, und dem, was der Browser ausführt, liegt eine Übersetzung, die man kennen muss, wenn etwas schiefgeht. Eine Fehlermeldung aus einer generierten Render-Funktion oder ein Effekt, der zu oft läuft, führt direkt in die Interna des Frameworks.

Wo Abstraktion kostet und wo sie sich auszahlt

Kritiker rechnen gern vor, wie viele Schichten zwischen Code und Bildschirm liegen. Das ist richtig, aber unvollständig. Eine ehrliche Bilanz sieht so aus.

Der virtuelle DOM als Kompromiss

React hat den virtuellen DOM populär gemacht: Die Oberfläche wird bei jeder Änderung als leichtgewichtige Kopie neu berechnet, mit der alten verglichen, und nur die Unterschiede gehen in den echten DOM. Das Verfahren war nie die schnellste Methode, DOM zu aktualisieren, sondern eine bequeme. Es erlaubt, die Oberfläche als reine Funktion des Zustands zu denken, ohne sich um einzelne DOM-Knoten zu kümmern.

Die Kosten zeigen sich bei Oberflächen mit sehr vielen, sehr häufigen Änderungen. Angenommen, ein Leitstand zeigt hundert Maschinen mit Messwerten, die mehrmals pro Sekunde aktualisiert werden. Rechnet das Framework bei jedem Messwert größere Teile des Komponentenbaums neu, frisst das Rechenzeit, die auf einem Industrie-Tablet spürbar fehlt. Die Lösung liegt dann meist in feinerer Zerlegung, Memoisierung oder darin, einzelne Bereiche am Framework vorbei direkt zu zeichnen, etwa in ein Canvas-Element. Wie Frameworks Änderungen im Detail in das DOM übertragen, beschreibt der Beitrag JavaScript-Frameworks und das DOM.

Wrapper um gewöhnliche Bibliotheken

Ein zweiter Kostenpunkt sind Anpassungsschichten. Für Diagrammbibliotheken wie D3, für Karten, Rich-Text-Editoren oder 3D-Grafik gibt es fast immer eigene Pakete für React, Vue oder Angular. Sie fügen kaum Funktionen hinzu. Sie lösen ein Zuständigkeitsproblem: Das Framework will das DOM kontrollieren, die Bibliothek auch. Der Wrapper vermittelt zwischen beiden und bindet die Bibliothek an den Lebenszyklus der Komponente.

Jede solche Schicht ist eine weitere Abhängigkeit mit eigenem Release-Rhythmus. Wird sie nicht mehr gepflegt, hängt ein Projekt beim nächsten Framework-Update fest. In vielen Fällen ist es wartungsärmer, die Bibliothek direkt einzubinden und ihr per Referenz ein eigenes DOM-Element zu überlassen. Das funktioniert in allen gängigen Frameworks, wird aber selten so gelehrt.

Wo die Abstraktion trägt

Gegen die Kritik steht eine einfache Beobachtung: Große Oberflächen mit vielen Entwickler:innen waren vor den Komponenten-Frameworks schwer beherrschbar. Wer eine jQuery-Anwendung mit hundert Masken gewartet hat, in der beliebiger Code an beliebiger Stelle das DOM verändert, weiß, warum sich das deklarative Modell durchgesetzt hat. Die Abstraktion kostet Rechenzeit und Verständnis, sie kauft dafür Vorhersagbarkeit im Team.

Signals: Die Reaktivität wächst zusammen

Die interessanteste Entwicklung der letzten Jahre widerspricht der These vom Stillstand teilweise. Fast alle Frameworks sind bei der Reaktivität auf dasselbe Modell umgeschwenkt: Signals. Ein Signal ist ein Wert, der sich merkt, welcher Code ihn gelesen hat, und genau diesen Code bei einer Änderung erneut ausführt. Statt einen ganzen Komponentenbaum neu zu berechnen, wird nur die betroffene Stelle aktualisiert.

Solid hat das Prinzip im Frontend bekannt gemacht, Preact bietet es als eigene Bibliothek an, Angular baut seit Version 16 darauf um, Vue nutzt es intern schon seit Version 2 (seit Version 3 über Proxies), und Svelte 5 hat seine Runes ($state, $derived, $effect) darauf gestellt. Bei TC39, dem Gremium für den JavaScript-Standard, liegt seit 2024 ein Vorschlag, Signals direkt in die Sprache aufzunehmen. Er befindet sich noch in einem frühen Stadium.

Wie wenig Magie dahintersteckt, zeigt eine stark vereinfachte Umsetzung in reinem JavaScript:

let aktuellerEffekt = null;

export function signal(startwert) {
  let wert = startwert;
  const abonnenten = new Set();
  return {
    get() {
      if (aktuellerEffekt) abonnenten.add(aktuellerEffekt);
      return wert;
    },
    set(neu) {
      if (Object.is(neu, wert)) return;
      wert = neu;
      for (const effekt of [...abonnenten]) effekt();
    },
  };
}

export function effect(fn) {
  const ausfuehren = () => {
    const vorher = aktuellerEffekt;
    aktuellerEffekt = ausfuehren;
    try {
      fn();
    } finally {
      aktuellerEffekt = vorher;
    }
  };
  ausfuehren();
}

// Anwendung: Der Effekt läuft nur, wenn sich anzahl ändert
const anzahl = signal(0);
const ausgabe = document.querySelector('#anzahl');
effect(() => {
  ausgabe.textContent = `Artikel im Warenkorb: ${anzahl.get()}`;
});
document.querySelector('#plus').addEventListener('click', () => {
  anzahl.set(anzahl.get() + 1);
});

Echte Implementierungen kümmern sich zusätzlich um abgeleitete Werte, das Aufräumen alter Abhängigkeiten und das Bündeln mehrerer Änderungen. Das Grundprinzip passt aber auf eine Bildschirmseite.

Für die Paradigmen-Frage ist das ein zweischneidiges Ergebnis. Einerseits haben die Frameworks ein besseres Modell gefunden und es erstaunlich schnell übernommen, selbst Angular mit seiner großen Unternehmensbasis. Andererseits ist die Monokultur damit eher größer geworden: Die Frameworks unterscheiden sich in der Reaktivität heute weniger als vor fünf Jahren. React geht als einziges großes Framework einen anderen Weg und lässt seit 2025 einen Compiler die Memoisierung übernehmen, die Signals überflüssig machen würden.

Server-first: Ein altes Paradigma kommt zurück

Das zweite Grundmodell ist älter als alle Frontend-Frameworks: Der Server erzeugt HTML, der Browser zeigt es an. Jahrelang galt das als überholt. Inzwischen kehrt es in mehreren Varianten zurück.

• React Server Components führen Komponenten auf dem Server aus und schicken das Ergebnis an den Browser. Nur Komponenten, die Interaktion brauchen, landen als JavaScript beim Client. Wie sich das auf Komponentenschnitt und Zustandsverwaltung auswirkt, behandelt der Beitrag React-Architektur: Komponenten, Zustand und Performance.
• Inselarchitektur („Islands“), bekannt durch Astro, liefert statisches HTML und macht nur einzelne Bereiche interaktiv, etwa eine Suche oder einen Warenkorb.
• Resumability, das Prinzip von Qwik, setzt die auf dem Server begonnene Ausführung im Browser fort, statt die ganze Anwendung beim Laden erneut zu starten.
• HTML über die Leitung, etwa mit htmx oder Hotwire, verzichtet fast ganz auf clientseitige Logik. Ein Klick lädt ein HTML-Fragment vom Server und ersetzt damit einen Teil der Seite. Wie weit das trägt, zeigt der Beitrag htmx: Webanwendungen ohne JavaScript-Framework.

Hier entsteht tatsächlich Vielfalt. Die Varianten beantworten die Frage, wo Code laufen soll, sehr unterschiedlich. Für Teams heißt das: Die wichtigere Entscheidung ist oft nicht „React oder Vue“, sondern „wie viel Logik gehört überhaupt in den Browser“. Ein internes Bestellformular mit Validierung braucht keine Single-Page-Anwendung. Ein kollaborativer Editor, in dem mehrere Personen gleichzeitig schreiben, kommt ohne umfangreiche Logik im Browser nicht aus.

Ohne Build-Schritt: Was die Plattform heute selbst kann

Das dritte Paradigma ist das radikalste: auf ein Framework weitgehend verzichten und direkt mit den Webstandards arbeiten. Vor zehn Jahren war das für größere Anwendungen kaum realistisch. Heute bringen die Browser vieles mit, wofür früher Werkzeuge nötig waren: ES-Module laden Code ohne Bundler, Import Maps lösen Paketnamen auf, Web Components kapseln eigene HTML-Elemente, und CSS beherrscht Verschachtelung, Container Queries und den :has()-Selektor.

Eine kleine Komponente ohne Build-Schritt sieht so aus:

<script type="importmap">
  {
    "imports": {
      "lit": "https://cdn.jsdelivr.net/npm/lit@3/+esm"
    }
  }
</script>

<script type="module">
  import { LitElement, html } from 'lit';

  class LagerBestand extends LitElement {
    static properties = { menge: { type: Number } };

    constructor() {
      super();
      this.menge = 0;
    }

    render() {
      return html`
        <p>Bestand: ${this.menge} Stück</p>
        <button @click=${() => this.menge++}>Zugang buchen</button>
      `;
    }
  }

  customElements.define('lager-bestand', LagerBestand);
</script>

<lager-bestand menge="12"></lager-bestand>

Lit ist eine kleine Bibliothek über dem Web-Components-Standard. Die Datei läuft so im Browser, ohne Compiler und ohne Entwicklungsserver. Für Produktivbetrieb sollten Sie Abhängigkeiten allerdings selbst ausliefern statt aus einem fremden CDN, schon aus Datenschutz- und Verfügbarkeitsgründen.

Der Verzicht hat einen Preis, der in Grundsatzdebatten gern kleingeredet wird. Ohne Build-Schritt fehlen TypeScript-Prüfung, Minifizierung und das automatische Aufteilen des Codes. Ohne Framework fehlen Konventionen, auf die sich ein wachsendes Team stützen kann, und Werkzeuge wie die React- oder Vue-DevTools. Die Browser-Entwicklerwerkzeuge sind mächtig, sie zeigen aber DOM und Netzwerk, nicht den Zustand einer Anwendung. Für eine kleine Fachanwendung oder ein Designsystem, das in mehreren Frameworks funktionieren soll, ist der Weg trotzdem attraktiv. Für eine große Anwendung mit wechselnden Teams baut man sich ohne Framework schnell ein eigenes, nur ohne Dokumentation.

Warum etablierte Frameworks nur in Schritten umbauen

Je erfolgreicher ein Framework ist, desto vorsichtiger muss es sich verändern. Millionen Komponenten, Schulungsunterlagen und Bibliotheken hängen an seinen Grundentscheidungen. React kann JSX nicht abschaffen, Vue nicht seine Templates, Angular nicht die Dependency Injection.

Die Jahre seit 2023 zeigen aber, dass „in Schritten“ nicht „gar nicht“ heißt. Angular kommt seit Version 21 standardmäßig ohne Zone.js aus, das jahrelang das Herz seiner Änderungserkennung war, und hat mit Version 19 Standalone-Komponenten statt NgModules zum Standard gemacht. Vue arbeitet am Vapor Mode, der ohne virtuellen DOM auskommt. React hat mit Server Components das Modell, wo Code läuft, grundlegend erweitert. Diese Umbauten geschehen jeweils mit langen Übergangsphasen, in denen alter und neuer Stil nebeneinander funktionieren.

Für Teams bedeutet das eine eigene Last: Eine Codebasis enthält nach einigen Jahren mehrere Generationen desselben Frameworks. Angular-Projekte mischen RxJS und Signals, React-Projekte Klassenkomponenten, Hooks und Server Components. Der Wartungsaufwand entsteht weniger durch das Framework selbst als durch diese Schichten.

Die Kaskade der Abhängigkeiten

Hinzu kommen Abhängigkeiten, die sich gegenseitig blockieren. Ein Framework-Update setzt eine neue Version des Build-Werkzeugs voraus, die alte Plugins nicht mehr unterstützt, deren Nachfolger wiederum eine neue Version der Komponentenbibliothek verlangen. Angenommen, ein Team will nur eine Sicherheitslücke in einer Bibliothek schließen und stellt fest, dass das Update eine neue Node.js-Version, ein neues Testwerkzeug und eine angepasste Build-Konfiguration nach sich zieht. Aus einer halben Stunde werden zwei Wochen.

Das ist kein Plan einzelner Hersteller, sondern die Folge vieler kleiner Abhängigkeiten mit eigenem Takt. Wirksam dagegen sind wenige, bewusst gewählte Abhängigkeiten, regelmäßige kleine Updates statt seltener großer und automatisierte Tests, die ein Update absichern.

Hausgemachte Komplexität: Zustand, Routing, Tests

Ein Teil der Komplexität im Frontend ist nicht dem Paradigma geschuldet, sondern Gewohnheit.

Zustandsverwaltung ist das bekannteste Beispiel. Redux, MobX, Zustand, Jotai, Pinia, NgRx: Die Auswahl suggeriert, Zustand sei ein schwieriges Problem. Für einen großen Teil der Anwendungen ist er das nicht. Lokaler Zustand gehört in die Komponente, gemeinsamer Zustand in wenige klar benannte Stellen. Schwierig wird es bei Daten vom Server, die zwischengespeichert, aktualisiert und mit anderen Nutzern abgeglichen werden müssen. Dafür haben sich spezialisierte Bibliotheken wie TanStack Query bewährt. Eine globale Store-Bibliothek ist dann oft überflüssig. Mit Signals wird lokaler und gemeinsamer Zustand zudem deutlich einfacher, weil ein Signal in einem gewöhnlichen Modul liegen kann.

Routing wirkt auf den ersten Blick trivial: je nach URL einen anderen Inhalt zeigen. In der Praxis kommen Datenladen vor dem Anzeigen, verschachtelte Layouts, Zugriffsschutz und Codeaufteilung hinzu. Dafür sind Router-Bibliotheken sinnvoll. Überflüssig sind sie dort, wo eine Anwendung ohnehin aus wenigen Seiten besteht, die der Server ausliefern könnte.

Tests brauchen dagegen vor allem eine saubere Trennung: Geschäftslogik in gewöhnlichen Funktionen lässt sich ohne Framework testen, nur die Darstellung braucht Werkzeuge wie Testing Library oder ein Browser-Testwerkzeug wie Playwright. Teams, die alles über Komponententests prüfen, testen häufig mehr Framework als eigene Logik.

Was das für Ihr Team bedeutet

Die These vom Paradigmenmangel trifft auf die Reaktivität heute stärker zu als je zuvor, denn hier haben sich fast alle Frameworks auf Signals geeinigt. Bei der Frage, wo Code läuft, ist dagegen echte Vielfalt entstanden: Server Components, Inseln, Resumability und HTML über die Leitung sind unterschiedliche Antworten auf dieselbe Frage. Und die Webplattform ist inzwischen so weit, dass der Verzicht auf ein Framework für kleinere Vorhaben eine ernsthafte Option ist.

Unsere Empfehlung: Stellen Sie die Paradigmen-Frage vor der Produktfrage. Klären Sie zuerst, wie viel Logik in den Browser gehört, wie häufig sich die Oberfläche ändert und wie groß das Team in fünf Jahren sein wird. Erst danach lohnt der Vergleich einzelner Frameworks, wie ihn der Beitrag Frontend-Frameworks im Vergleich: Angular, React, Vue und Svelte anstellt. Überschätzt wird dabei die Wahl des „richtigen“ Frameworks, unterschätzt die Disziplin, mit wenigen Abhängigkeiten auszukommen und Geschäftslogik vom Framework fernzuhalten. Code, der nicht an ein Framework gebunden ist, überlebt auch den nächsten Wechsel.

Wer Frontend-Architekturen auf diese Fragen hin prüfen oder ein Team darin schulen will, findet bei uns Beratung, Coaching und Seminare zur Frontend-Architektur.

Häufige Fragen zu Paradigmen in JavaScript-Frameworks

Sind template-basierte Frameworks schlecht?

Nein. React, Vue, Angular und Svelte lösen reale Probleme, vor allem die Koordination großer Teams an großen Oberflächen. Die Kritik richtet sich gegen die Annahme, jedes Webprojekt brauche automatisch ein solches Framework. Für viele Vorhaben gibt es inzwischen einfachere Wege, die mit weniger Abhängigkeiten auskommen.

Werden Signals Teil von JavaScript?

Es gibt einen entsprechenden Vorschlag bei TC39, er ist aber noch weit von einer Aufnahme in den Standard entfernt. Selbst wenn er kommt, würden Frameworks Signals vermutlich weiterhin mit eigenen Komfortfunktionen umhüllen. Der Vorteil läge vor allem darin, dass Bibliotheken unterschiedlicher Frameworks denselben Reaktivitätskern teilen könnten.

Welche Rolle spielt TypeScript in dieser Debatte?

TypeScript fügt zur Laufzeit keine Schicht hinzu, es wird vor der Auslieferung in gewöhnliches JavaScript übersetzt. Es erweitert die Sprache um Typprüfung, ohne ein eigenes Programmiermodell vorzugeben, und funktioniert mit jedem der hier beschriebenen Ansätze. Der einzige Konflikt besteht mit dem Wunsch nach völligem Verzicht auf einen Build-Schritt. Node.js kann Typannotationen inzwischen direkt entfernen, im Browser ist dafür aber weiterhin ein Werkzeug nötig.

Wie lässt sich eine bestehende Anwendung schrittweise vereinfachen?

Ein vollständiger Neubau ist selten wirtschaftlich. Sinnvoller ist es, Geschäftslogik nach und nach aus Komponenten in gewöhnliche TypeScript-Module zu verlagern, überflüssige Abhängigkeiten zu entfernen und neue, wenig interaktive Seiten serverseitig auszuliefern. So sinkt die Bindung an das Framework, ohne dass der laufende Betrieb leidet.