React siegt als Standardwahl und bremst die Innovation im Frontend

• Heute erfolgt die Einführung von React nicht wegen technischer Überlegenheit, sondern als Standardwahl, was die Innovation im Frontend-Ökosystem verlangsamt
• Viele Teams wählen ohne Prüfung der Rahmenbedingungen das „React, das alle kennen“, wodurch Netzwerkeffekte Architekturentscheidungen stärker bestimmen als technische Eignung
• Innovative Frameworks wie Svelte, Solid und Qwik bieten bessere Performance-Modelle, werden aber wegen mangelnder Verbreitung im Mainstream-Wettbewerb zurückgedrängt
• React hat viele Stärken, doch das Problem ist die React-als-Standard-Denkweise, die Opportunitätskosten erhöht und den Blick auf bessere Alternativen verstellt
• Für ein gesundes Ökosystem braucht es Vielfalt und Wettbewerb; die Botschaft lautet, Frameworks nicht als Standard, sondern nach Rahmenbedingungen und Eignung auszuwählen

---

Reacts Sieg als Standardwahl und seine Grenzen

• React wird nicht mehr primär wegen technischer Überlegenheit gewählt, sondern häufig als Standard eingeführt
  • Das verstärkt die Gewohnheit von Teams, automatisch React zu nutzen, ohne die Rahmenbedingungen eines Projekts zu bewerten
• Alternative Frameworks (Svelte, Solid, Qwik) werden nicht angemessen evaluiert, obwohl sie in bestimmten Szenarien Performance-Vorteile gegenüber React haben
• Weniger React selbst ist das Problem als vielmehr die React-als-Standard-Denkweise, die eine Struktur schafft, welche Innovation hemmt

Die Decke der Innovation

• Reacts Virtual DOM war 2013 passend, verursacht heute jedoch unnötigen Overhead
• Hooks lösten die Probleme von Klassenkomponenten, führten aber neue Komplexität ein, etwa Dependency Arrays und stale closures
• Server Components und der React Compiler versuchen, die Performance zu verbessern, sind aber letztlich Umgehungslösungen für die Grenzen des React-Modells
• Dagegen zeigen Sveltes Runes, Solids feingranulare Reaktivität und Qwiks Resumability mit völlig anderen Modellen ein deutlich höheres Potenzial

Technische Schulden

• Wer React standardmäßig wählt, nimmt unnötige Laufzeitkosten und den Aufwand für das Management von Re-Renders in Kauf
• Entwickler verbringen dann Zeit mit Effect-Abhängigkeiten oder Hydration-Management statt mit Business-Mehrwert
• In Benchmarks zeigt Solid eine 2- bis 3-mal schnellere Update-Performance als React
• Ein auf React-Mustern basierendes Denken schwächt die Grundlagen des Webs und verstärkt architektonische Trägheit

Alternative Frameworks

• Svelte: die Compiler-Revolution

  • Svelte erledigt den Großteil der Arbeit zur Compile-Zeit und beseitigt den virtual DOM
  • Komponenten rücken näher an die Grundstruktur des Webs, und der Runtime-Overhead sinkt deutlich
  • Dennoch ist die Einführungsrate gering, weil die Wahrnehmung besteht, dass es „wenige Jobchancen“ gebe
  • Verschiedene Beispiele wie The Guardian, Wired und Shawn Wang zeigen, dass nach der Einführung von Svelte Bundle-Größe und Ladezeit stark sanken und die Entwicklerproduktivität stieg
  • Shawn Wang etwa reduzierte die Größe seiner Website von 187KB mit React auf 9KB mit Svelte

• Solid: ein direkter Ansatz für feingranulare Reaktivität

  • Solid kombiniert präzise Reaktivität (feingranulare Reaktivität) mit JSX-Syntax
  • Über Signals greift es direkt nur auf das geänderte DOM zu und umgeht damit den Reconciliation-Flaschenhals vollständig
  • Es bietet starke Performance und eine schlanke Zustandsverwaltung
  • Die Zahl der Praxisbeispiele ist noch begrenzt, doch Berichte aus frühen Teams zeigen große Fortschritte sowohl bei Effizienz als auch bei der Einfachheit des Codes

• Qwik: die Innovation der Resumability

  • Qwiks Stärke ist statt traditioneller Hydration Resumability, was einen sofortigen Start ermöglicht
  • Nur aktuell benötigte Funktionen werden schrittweise geladen, und sowohl Zustand als auch Code lassen sich serialisieren
  • Gerade bei großen Websites, langen Sessions und langsamen Netzwerken zeigt es hervorragende Ergebnisse
  • Noch wagen es nicht viele Teams, doch die Teams, die es eingeführt haben, berichten von deutlichen Verbesserungen sowohl bei initialen Ladezeiten als auch bei Ressourceneffizienz

• Die Komplexität der React-API und die Einfachheit alternativer Frameworks

  • Die React-API umfasst komplexe Konzepte wie hook, context, reducer, memoization usw., was die kognitive Belastung für Entwickler erhöht
  • Bei Fehlgebrauch entstehen leicht Bugs durch Abhängigkeitsprobleme oder ein übermäßiger Designaufwand
  • So wurde etwa der Ausfall von Cloudflare am 12. September 2025 durch einen Fehler bei der Konfiguration des Dependency Array von useEffect verursacht
  • Alternativen wie Svelte, Solid und Qwik setzen dagegen mit deutlich kleineren und fokussierteren APIs auf Einfachheit und die grundlegenden Prinzipien des Webs
  • Alle drei Frameworks haben genügend technische Vorteile, werden aber durch die Kultur von React als Standard oft nicht einmal experimentell erprobt

Das Gefängnis der Netzwerkeffekte

• Die Dominanz von React schafft selbstverstärkende Barrieren
• Auf dem Arbeitsmarkt werden nur „React-Entwickler“ gesucht, und in Organisationen verfestigen sich Komponentenbibliotheken und Entwicklungsgewohnheiten rund um React
• Führungskräfte, die Risiken vermeiden wollen, wählen folgerichtig das vermeintlich sichere React, und Bildungseinrichtungen richten sich ebenfalls danach aus
• Diese Struktur ist ein Kennzeichen eines Ökosystems, in dem gesunder Wettbewerb verschwunden ist

Netzwerkeffekte aufbrechen

• Um daraus auszubrechen, braucht es bewusste Entscheidungen
• Technische Führungskräfte müssen Trägheit ablegen und Strukturen nach Anforderungen festlegen; Unternehmen können Budgets für Pilotprojekte bereitstellen, um Alternativen zu testen
• Auch Entwickler sollten nicht an einem einzigen Paradigma festhalten, sondern die Denkweisen verschiedener Frameworks erlernen
• Bildungseinrichtungen sollten mehr Unterricht zu framework-agnostischen Konzepten anbieten, und Open-Source-Mitwirkende können kleinere Ökosysteme gezielt unterstützen
  Veränderung kommt nicht von selbst, sie muss bewusst geschaffen werden.

Checkliste zur Bewertung von Frameworks

Bei neuen Projekten können folgende Kriterien als Bewertungsmaßstab dienen

• Performance-Anforderungen: initiale Ladezeit, Update-Effizienz, Bundle-Größe sowie die Frage, ob Compile-Zeit-Optimierungen möglich sind
• Teamfähigkeiten und Lernkurve: bestehende Erfahrung berücksichtigen; es gibt auch Alternativen wie Solid, die mit React verwandt wirken
• Skalierbarkeit und Total Cost of Ownership: langfristige Kosten inklusive Wartung, Abhängigkeitsmanagement und technischer Schulden bewerten
• Ökosystem-Fit: Balance zwischen Reifegrad und Innovationskraft, Pilotversuche in nicht kritischen Bereichen und ROI-Tests

Häufige Gegenargumente und Reaktionen

• Reife des Ökosystems: Ein älteres Ökosystem ist nicht automatisch besser für die Probleme von heute geeignet. Hohe Abhängigkeit von Third-Party-Paketen bringt Nebenwirkungen wie Wartungsaufwand, Sicherheitslücken und aufgeblähte Bundles mit sich. Kleinere Ökosysteme können sich stärker auf die Grundlagen des Webs konzentrieren, und dank Fortschritten bei AI-Tools lassen sich Custom Solutions leicht und schnell entwickeln.
• Hiring-Probleme: Nachfrage wird schnell zum Maßstab beim Hiring. Nach Tests von Alternativen in nicht zentralen Bereichen können fehlende Fähigkeiten durch Lernen in der Praxis ausgeglichen werden.
• Komponentenbibliotheken: Mit framework-unabhängigen Design-Systemen und dem Einsatz von Web Components lässt sich Lock-in reduzieren und die Produktivität erhalten.
• Stabilität: Auch React verändert sich mit Hooks, Server Components usw. ständig. Alternative Frameworks bieten oft sogar konsistentere APIs.
• Bedarf an Nachweisen in großem Maßstab: Auch jQuery war einst ein weltweites Erfolgsbeispiel. Vergangener Erfolg ist keine Garantie dafür, dass er in Zukunft noch gilt.

Schaden für Ökosystem und Branche insgesamt

• Eine Monokultur rund um React verlangsamt die Weiterentwicklung des Webs selbst
• Talent und Kapital fließen nur noch in die Lösung von React-Problemen, während plattformspezifische Innovation verzögert wird
• Auch Bildungseinrichtungen fördern durch Curricula mit Fokus auf sofortige Beschäftigungsfähigkeit vor allem schwer übertragbare Technikkenntnisse
• Die Weiterentwicklung der Plattform selbst wird von der Antwort „React reicht doch“ blockiert, und die fehlende Vielfalt im Ökosystem fällt langfristig auf alle zurück

Das wünschenswerte Ökosystem, das wir schaffen können

• Vielfalt ist eine Grundvoraussetzung für ein gesundes Ökosystem
• Innovation entsteht, wenn mehrere Paradigmen miteinander konkurrieren und sich austauschen
• Entwickler wachsen, indem sie verschiedene Denkweisen kennenlernen, und auch die Web-Plattform selbst entwickelt sich dank vielfältiger Experimentierfreude weiter

• Alles auf ein Framework zu setzen, schafft einen Single Point of Failure. Wird seine Grenze erreicht, stagniert das Wachstum, und bessere Chancen verschwinden
• Für jedes Projekt sollte die Wahl anhand technischer Rahmenbedingungen und Eignung getroffen werden; eine Haltung, die sich nicht nur auf React als Standard verlässt, ist notwendig
• Nur Vielfalt garantiert echte Innovation

• Es ist an der Zeit, nicht länger alle denselben „Samen“ namens React zu pflanzen, sondern durch vielfältigere Framework-Experimente das Web-Ökosystem robuster und innovativer zu machen
• Die Wahl liegt bei uns