- 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
useEffectverursacht - 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
19 Kommentare
Dass Junior-Entwickler React wählen, ist unvermeidlich, aber es ist ein Problem, wenn Senior-Entwickler aufhören, über andere Alternativen nachzudenken.
Es stimmt schon, dass React oder Java uralter Schrott sind, obwohl es inzwischen viel bessere Alternativen gibt, und trotzdem kassieren sie damit schon viel zu lange ab, haha.
Mit Experimenten wurde in der letzten großen chaotischen Framework-Ära viel herumprobiert ...
Im Arbeitsalltag gibt es keinen Bedarf, das Bestehende komplett umzukrempeln, und selbst bei neuen Projekten gibt es wegen Einstellungsfragen nicht viele, die zustimmen würden, etwas aufzugeben, das man bislang gut genutzt hat, um stattdessen etwas Neues zu lernen und umzusteigen.
Ich hoffe wirklich, dass sich Solid gut entwickelt … Wie man dieses React-Monopol aufbrechen soll, ist die Frage.
Im FE-Ökosystem sind in den letzten fast zehn Jahren unzählige Tools auf den Markt gekommen, und nach Aufstieg und Fall vieler davon hat sich die Lage nun endlich einigermaßen stabilisiert – und jetzt soll man erneut ein solches totales Chaos versuchen..
Ein viel zu voreingenommener Artikel, oder? „Innovative Frameworks wie Svelte, Solid und Qwik bieten bessere Performance-Modelle, bleiben aber wegen mangelnder Akzeptanz im Wettbewerb um den Mainstream zurück.“
Wenn es keinen konsistenten Maßstab dafür gibt, was das Wort „Innovation“ überhaupt bedeutet, dann scheint schon die Ausgangsannahme falsch zu sein.
Wenn ich solche Beiträge sehe, denke ich, dass der Fokus eher nur auf Software Engineering liegt als darauf, tatsächlich ein Produkt zu bauen. Am Ende ist das alles ohnehin mehr oder weniger ähnlich, deshalb muss man vor allem ein gutes Produkt entwickeln, statt ständig nach neuen Frameworks und neuen Architekturen zu suchen, alles zu overengineeren und dann wieder zu sagen, dass das hier besser sei und man erneut wechseln solle. Ich finde, wichtig ist nicht, dass etwas neu ist, sondern dass man das, was man hat, gut einsetzt und ein Produkt auf den Markt bringt.
Das ist kaum zu vermeiden, weil große Tech-Unternehmen hierzulande auf Basis von React (
next.js) einstellen.Selbst für das große
vue.jsgibt es bei Big Tech nicht viele offene Stellen.Man kann das Ökosystem einfach nicht ignorieren … Die meisten Third-Party- oder Open-Source-Bibliotheken, die heutzutage erscheinen, unterstützen React offiziell, während andere Frameworks oft nur Community-Support haben. Wenn man also dieses und jenes kombiniert einsetzen will, bleibt React am Ende praktisch die sicherste Wahl …
Wo gäbe es schon ein Feld, das so vielfältig experimentiert wie das Frontend ...
Dank des Engagements des React-Entwicklerteams bei Facebook ist die Entwicklung von Web-Apps anspruchsvoller geworden. Kein Bösewicht … hat aber der Ära von PHP und jQuery ein Ende bereitet.
Hacker-News-Kommentar
Ich denke nicht, dass React einfach nur zum Default geworden ist, sondern dass es so effektiv und gut designt war, dass es de facto zum Standard wurde — und inzwischen gleichzeitig zum Bösewicht gemacht wird.
Die Behauptung, React würde Innovation verlangsamen, wirkt auf mich ziemlich absurd.
React ist unter zahllosen „Ich will auch mitmachen“-Frameworks und verwirrenden Designs praktisch die einzige stabile und vernünftige Wahl.
Dem stimme ich höflich nicht zu.
Ich habe nie komplexe interaktive Apps mit React gebaut, nur ein paar einfache Websites, bei denen Teammitglieder React schon vorher gewählt hatten.
Mein Eindruck war dabei eher, dass React sich für einfache Seiten eindeutig nicht gut herunterskalieren lässt.
Für eine einfache Login-Seite kann man den Status direkt im DOM speichern und Werte einfach mit einem
<form>absenden, und für Passwort anzeigen/verbergen braucht man nur ein wenig JS.Mit React muss man dagegen JSX, Hooks, den Component Lifecycle, Development Builds, Production Packaging und vieles mehr lernen.
Andere Frameworks wie Vue oder Alpine lassen sich „progressiv“ einsetzen und sogar direkt per CDN starten.
React behauptet zwar ebenfalls, progressiv zu sein, aber wegen JSX ist ein Build-/Compile-Prozess praktisch Pflicht, und in der offiziellen Dokumentation gibt es keinen direkten CDN-Einstieg.
Unmöglich ist es nicht, aber dann müsste man am Ende auch noch den Compiler an den Client ausliefern, was in der Praxis ziemlich katastrophal ist.
Die meisten Websites sind nicht auf dem Niveau von Facebook, Spotify oder Netflix (wobei sogar Netflix angekündigt hat, sich von React zu entfernen), daher fällt es mir schwer zuzustimmen, dass React so effektiv und gut designt sei.
Als React vor 12 Jahren erschien, war es wirklich innovativ.
Kurz darauf kamen jedoch mehrere ähnliche Frameworks, und seitdem blieb es eher bei „ganz brauchbar“, statt das Zentrum der Innovation zu sein.
Inzwischen löst es Probleme eines veralteten Virtual-DOM-Designs, während gleichzeitig immer mehr Boilerplate entsteht, und gegenüber modernen Alternativen wird es immer unattraktiver.
Die Bedeutung des Titels ist umgekehrt.
Eigentlich fühlt es sich eher so an, als würde die „Innovation“ die React-Formel, also die Erfolgsformel, nicht einholen.
Man sollte sich auch fragen, wie viel Innovation überhaupt nötig ist.
Oft sind Wiederholung und schrittweise Verbesserung besser und günstiger.
Ich mag diesen Artikel und die pluralistische Perspektive von 2015–16.
Ich würde im Team gern sagen: „Lasst uns einen kleinen separaten Use Case mit Svelte bauen“, aber die Bewertungs-Checkliste wirkt genau entgegengesetzt zu dem, was der Artikel fordert.
Performance: Bei 99 % der Apps spürt man keinen Unterschied, also am Ende doch React.
Teamkenntnisse und Lernkurve: Alle kennen nur React, Qwik und Ähnliches kennt niemand. Also wieder React.
Skalierbarkeit, Betriebskosten: Kein großer Unterschied.
Ökosystem: React ist viel größer und stabiler. Also React.
Dazu kommt, dass heutige AI-Tools mit React gut zurechtkommen und Entwickler fast automatisch React-zentriert lernen.
Am Ende bleibt React praktisch zwangsläufig die vernünftige Wahl.
Ich glaube, dass Web Components ein Ausweg aus dieser Oligopolsituation der Frameworks sind.
Alle Frameworks außer React unterstützen Web Components aktiv, und der Weg heraus besteht darin, kompatible Komponenten- und Utility-Ökosysteme zu nutzen, statt jeweils ein eigenes React-Ökosystem neu aufzubauen.
Viele sehen Web Components als Konkurrenten im Framework-Wettbewerb, tatsächlich definieren sie aber die Schnittstelle zwischen Komponentenimplementierung und Browser und ermöglichen Interoperabilität sowie eine verlässliche Zusammensetzung.
Auf solchen Low-Level-APIs kann es weiterhin unterschiedliche Arten geben, Komponenten zu erstellen — buildless, mit JSX, Templates, eigener Syntax, Compiler usw. — ebenso wie Innovationen bei der Komposition von Komponenten und beim State Management.
Um das React-Monopol zu überwinden, muss man damit werben können: „Unser neues Flugle-Framework funktioniert mit jedem Framework und hat reichlich Automatisierungstools!“
Ich verwende ebenfalls Wrapper, um Web Components ohne Boilerplate zu nutzen.
So habe ich mit sehr wenig Aufwand 80 % der Vorteile von Web Components bekommen.
Zugehöriges GitHub: ZjsComponent, dazu auch die frühere HN-Diskussion (HN-Diskussion).
Es ist nicht perfekt, aber für mich gibt es keinen einfacheren und schnelleren Weg, neue HTML-Komponenten zu erstellen.
Wenn es keine Alternative auf dem Niveau von React Native gibt, reichen Web Components allein nicht aus.
Browser-Technologien sind nicht schnell genug, um das Niveau nativer Apps zu erreichen.
Der größte Wert von React liegt darin, GUI-Entwicklung plattformübergreifend zu vereinheitlichen.
Ich habe Business-Apps mit lit Web Components gebaut.
Dass alle Properties vom Typ string sein müssen, war ziemlich unpraktisch, und mit auf Echtzeit ausgelegten Komponentenbibliotheken war das nicht vergleichbar.
In unserem Großunternehmen müssen interne Apps zwingend eine zentrale React-Bibliothek verwenden.
Es ist nicht „React, weil es der Default ist“, sondern „nur React ist erlaubt“.
Ich denke, der Ausweg wäre, die zentrale Bibliothek als Web Components neu zu implementieren, damit man das gewünschte Framework verwenden kann.
Ich frage mich, ob jemand Web Components in einer React-UI-Bibliothek erfolgreich eingesetzt hat.
Wenn man eine Komponentenbibliothek passend zu einem bestimmten Design-System baut, finde ich die Abhängigkeit von einer headless Bibliothek wie RAC durchaus zufriedenstellend.
Ich verstehe, dass Web Components eine sinnvolle Ergänzung sein können, aber ich weiß nicht wirklich, wo sie in der Praxis am besten eingesetzt werden.
Eigentlich geht es in diesem Artikel nicht um die Performance von React, sondern darum, dass der „soziale Nutzen“ im Vergleich zu Alternativen viel größer ist und andere Entscheidungen dadurch schwer werden.
Mit anderen Worten: Selbst wenn React technisch nicht herausragt, ist es zur Default-Wahl geworden, und ich stimme zu, dass Netzwerkeffekte Entscheidungen stärker beeinflussen als technische Eignung.
Trotzdem haben Teams weiterhin klare Vorteile mit React gegenüber Alternativen.
Die meisten fähigen Teams erkennen ziemlich gut, dass sie nur in wirklich außergewöhnlichen Fällen etwas anderes wählen sollten.
Ich war in mehreren Unternehmen und Startups an Entscheidungen über den Tech-Stack beteiligt, aber ich habe nie erlebt, dass die Wahl von React mit „Vorteilen des Frameworks selbst“ begründet wurde.
Es ging immer um Vertrautheit, einfacheres Hiring und das Ökosystem.
Man nimmt an, Webentwickler würden rationale Entscheidungen treffen, aber meiner Erfahrung nach stimmt das nicht.
Menschen lassen sich leicht von kognitiven Verzerrungen wie „social proof“ oder „Autorität“ beeinflussen.
Ich habe noch nie gehört: „Wir verwenden React, weil es gut ist.“
Es heißt immer nur: „Weil Hiring damit einfacher ist.“
React ist stark bei der Lösung komplexer Probleme.
Aber nicht alle Probleme sind komplex, und wenn man ein komplexes Tool zum Default macht, bringt man unnötige Komplexität und geringere Flexibilität ins Projekt.
Auch die Instabilität eines Ökosystems, das aus Gründen vergangener oder zukünftiger Features gewartet werden muss, ist kein Problem, das auf React beschränkt wäre.
Ich hoffe, dass künftig neue Strömungen entstehen, die über das Web-App-Paradigma der aktuellen Generation hinausgehen.
Es gibt Gründe, sich über eine Monokultur im Frontend, also ein React-Monopol, Sorgen zu machen. Interessant ist aber, dass vor zehn Jahren die Lage komplett umgekehrt war.
Jede Woche tauchten neue Frameworks auf HN auf, das Chaos beim Übergang von Angular 1.x zu 2.0 war groß, und Frontend-Entwicklung war so mühsam, dass sogar der Begriff „JavaScript fatigue“ entstand.
Heute ist React klar als Standard etabliert, und dadurch kann man sich beruhigt auf die Entwicklung von Services konzentrieren.
Ich will React damit nicht verherrlichen — ich mag Hooks selbst auch nicht besonders —, aber ich bin froh, dass wir nicht mehr in Zeiten wie 2015 leben.
Interessant ist, dass sich die Stimmung mit der Zeit nun wieder langsam verändert.
Ich erinnere mich noch an die Zeit, als es geradezu verrückt viele Boutique-JavaScript-Bibliotheken gab.
Dass React sich durchgesetzt hat, sehe ich als eine Art Sieg.
Man sollte vorsichtig sein, Vertrautes und Stabiles nicht zwanghaft zugunsten eines vagen Begriffs von „Innovation“ aufzugeben.
Das kann ich wirklich gut nachvollziehen.
Von 2009 bis 2015 habe ich ziemlich früh viele browserbasierte UX auf dem Niveau nativer Apps gebaut.
Die Stärke lag in Webstandards und darin, sie so direkt wie möglich zu nutzen; später wechselte ich eher ins Backend und beobachtete den Aufstieg von React aus der Distanz.
React wirkte auf mich ineffizient, und auch die Beschränkung von JSX, dass „alles ein Ausdruck“ sein müsse, fand ich frustrierend.
Trotzdem rechne ich React hoch an, einen wichtigen Paradigmenwechsel im State Management gebracht zu haben.
Der Wechsel vom alten Zustandsmodell zu einem unidirektionalen immutable Data Flow war schmerzhaft, aber am Ende sinnvoll.
Auch in dieser chaotischen Zeit ist es wahr, dass React Innovation gebracht und die Denkweise über das Design von Web-Apps stark verändert hat.
Vergleicht man es heute aber mit SolidJS, bietet Solid dieselben Vorteile in kompakterer Form, mit besserer Performance und deutlich einfacherem Handling.
JSX, Server Components und reaktives State Management liefert es ebenfalls besser, und React-Entwickler können relativ leicht wechseln.
Auch die Denkweise beim App-Aufbau ist fast identisch, sodass man praktisch fast alle realen Vorteile von React in einer besseren, schnelleren und viel kleineren Bundle-Variante bekommt.
Trotzdem ist der ganze Markt so stark auf React ausgerichtet, dass man es widerwillig weiterverwenden muss.
Auch SolidJS hat noch Schwachstellen.
Das größte Problem ist, dass man oft nicht intuitiv erkennen kann, ob ein Prop ein Signal ist oder nicht.
Auch das Typsystem hilft da nicht besonders.
Bei React ist klar: Wenn sich die Referenz ändert, rendert die Stelle, die das Prop erhält, erneut. Bei Solid ist unklarer, ob eine Änderung tatsächlich beobachtet wird.
Ich glaube, die meisten Menschen sind damit zufrieden, einfach das zu verwenden, womit sie vertraut sind.
Viele Entwickler möchten React eigentlich nicht erzwungenermaßen nutzen, greifen am Ende aber doch dazu, was sie gut kennen.
Zeit ist begrenzt, und wegen Familie, Hobbys und anderem im Leben braucht man eine effiziente Wahl.
Man muss nicht zwangsläufig an React gebunden sein.
Es gibt auch ein Framework, das ich in meiner Firma — im Wesentlichen allein — in den letzten zehn Jahren entwickelt habe und das ich als Open Source unter der MIT-Lizenz veröffentlicht habe.
Q.js-Link
Ich würde gern Meinungen dazu hören.
Hooks haben die Nachteile von Class Components behoben, aber gleichzeitig neue Komplexität geschaffen, etwa Dependency Arrays, stale closures und Missbrauch.
Diese Probleme kommen jedoch nicht nur von Hooks; sie gab es auch schon bei den früheren klassenbasierten Komponenten.
Probleme mit Dependency Arrays entsprachen früher häufigen Bugs, weil Änderungen an Props oder State übersehen wurden.
Stale closures traten genauso beim zweiten Argument von
setStateauf.Auch Lifecycle-Methoden wie
componentDidMountodercomponentWillMountwurden häufig missbraucht.Ich denke, Dokumentation nach dem Muster „Verwende Effects nur, wenn es wirklich nötig ist“ wäre auch früher schon erforderlich gewesen.
Hooks tragen eindeutig zu Verbesserungen bei, weil sie Gelegenheiten für Fehler reduzieren, diese leichter sichtbar machen und sogar Warnungen liefern.
Das Problem mit Dependency Arrays lässt sich sehr leicht lösen, wenn man in eslint die Regeln zu react-hook verwendet.
Wenn man für Prop-Tests
fast-checknutzt, hilft das enorm dabei, Bugs bei kleineren Änderungen zu vermeiden.Die JavaScript-Community könnte Innovation vielleicht ruhig für ein paar Jahre pausieren.
Es gab zu viel Innovation mit zu wenig Substanz.
Jetzt sollten Browser selbst vernünftige Komponentenentwicklung für das Web übernehmen.
Wenn Browser etwa servergestützte Comboboxen oder einen standardisierten Date Picker bereitstellen würden, müsste man nicht jedes Mal wieder Innovationen für das State Management solcher grundlegenden UI-Controls erfinden.
Ich denke, ein Problem ist auch, dass Browser ihre ursprüngliche Rolle nicht mehr richtig erfüllen.
Google hat über Chrome einen beinahe monopolartigen Einfluss, und außerhalb dessen, wofür Google Interesse und Entwicklungsressourcen aufbringt, kommt selbst bei Webstandards wenig voran.
Safari und Firefox sorgen zwar in gewissem Maß für ein Gleichgewicht, aber wenn die Plattform sich wirklich zu etwas Differenziertem weiterentwickeln soll, müsste jemand Führung übernehmen und das konsequent vorantreiben.
Am Ende ist es bedauerlich, dass das JS-Ökosystem auf Plattformebene nicht die nötige Unterstützung bekommt und deshalb weiter alles zusammenhacken muss wie beim Flicken eines NAND-Chips.
Ich habe den Eindruck, dass Browser und CSS in letzter Zeit fortlaufend Use Cases verbessern oder lösen, die traditionell von JS abhingen.
Diese Entwicklung sollte sich gern weiter ausweiten.
Man könnte sogar darüber nachdenken, Browser in fünf oder sechs Typen wie Shopping, Banking oder Social aufzuteilen.
Dann könnten Services nur noch im Backend um Innovation konkurrieren, während das Frontend eine einheitliche Erfahrung bietet, was für Nutzer vorteilhafter wäre.
Dass jede Firma immer wieder separat dasselbe Frontend entwickelt, ist eine enorme Verschwendung.
Ein Sandwichladen sollte darum konkurrieren, bessere Sandwiches zu machen, statt ähnliche Frontends zu bauen, nur um 8 % mehr App-Installationen zu ergattern.
Eigentlich ist es schon erstaunlich, was Frameworks auf so einer komplexen Plattform wie HTML/CSS/JS überhaupt geschafft haben.
Das „Web“ war strukturell eher dafür geeignet, sich auf Dokumente, Text und einfache Formulare zu konzentrieren; für komplexe interaktive Apps ist es inzwischen eine sehr ungeeignete Grundlage.
Irgendwann muss das wohl komplett neu aufgebaut werden.
React hat nicht gewonnen, weil es „das Beste“ ist, sondern weil es zum „sicheren Default“ geworden ist.
Jeder kennt React, Hiring ist einfach, das Ökosystem ist groß — genau das macht es stabil.
Dadurch gibt es weniger Innovation, und leichtere Alternativen wie Svelte oder Solid werden oft gar nicht erst ausprobiert.
React funktioniert weiterhin gut, aber ich denke, in der Praxis wird es häufiger aus Trägheit als aus wirklicher Eignung verwendet.
Ich kann die Meinung des Autors nachvollziehen. Dennoch ist die Trägheit, React zu verwenden, nicht so falsch, wie es klingt. Wenn die erwähnten Alternativen wie Svelte das iPhone 17 wären, dann wäre React aus meiner Sicht etwa das iPhone 15 oder 16. Gemessen an den Kosten ist es noch immer brauchbar, und man spürt nicht unbedingt die Notwendigkeit, es zu wechseln. Dass wir React in der großen Phase des Frontend-Chaos gewählt haben, war anders als der Autor meint keine bewusste Entscheidung. Nachdem wir Verschiedenes ausprobiert hatten, wurde React gewählt, weil es sich am brauchbarsten anfühlte. Wenn React in Zukunft unpraktisch wird und etwas anderes nützlicher erscheint, wird es meiner Meinung nach auch ohne bewusste Herausforderung und Experimente ganz natürlich zu einem Wechsel kommen.
Wenn man sich den Krieg der Videokassettenstandards zwischen VHS und Betamax ansieht, scheint technisch Überlegenes nicht immer das zu sein, was sich am Markt durchsetzt.
Ist das Problem beim Frontend nicht eher, dass dort übermäßig viel unnötig innoviert wird?
Dem kann ich bis zu einem gewissen Grad zustimmen.
Da es auch im Backend eindeutig Aspekte gibt, bei denen die Produktivität steigt, wenn sich ein Framework wie Spring Boot bis hin zum E-Government-Framework zu einem Standardformat entwickelt, denke ich, dass React sich vielleicht ebenfalls in eine solche Richtung verändert.
Ja, ich denke, die Bedeutung von React liegt darin, dass es ein komponentenbasiertes Design und Rendering-Verhalten etabliert hat, das eine ziemlich große Mehrheit versteht. Allerdings ist React für sich genommen ein Framework auf niedrigem Niveau, um Web-Apps zu bauen, deshalb hätte ich mir gewünscht, dass zumindest ein Router und Formulare standardmäßig mitgeliefert werden. Und bei State und Effects frage ich mich, wie es gewesen wäre, wenn Deep Comparison standardmäßig unterstützt worden wäre und man die Logik nur mit Datenstrukturen und Funktionen hätte schreiben können. Wegen der Einschränkungen durch den flachen Vergleich in JavaScript landet man dann doch dabei, über die Syntax von Custom Hooks Klassen zu schreiben.
Eher niedrigschwellig … wobei … für die Implementierung von Formularen eigentlich schon ein
html-input-Tag reichen würde, man aber unnötig viel über State, JSX sowie unkontrollierte/kontrollierte Komponenten wissen muss und dabei viel Code erzeugt – ich vermute, dass genau solche Punkte die Motivation des Artikels waren.Sehe ich genauso.