Wenn nicht React, was dann?
(infrequently.org)> „Frameworkism (Framework-Ideologie) zieht nicht mehr. Die Antwort ist kein anderes Tool, sondern der Mut, tatsächlich Engineering zu betreiben.“
- In den vergangenen zehn Jahren Erfahrung mit mehr als 100 Projekten über verschiedene Produkte und Technologie-Stacks für Desktop- und Mobile-Web hinweg
- Viel Zeit floss nicht in die Verbesserung von Web-APIs, sondern in das Beheben von Performance- und Accessibility-Problemen, die Frontend-Frameworks wie React verursacht haben
- React ist bereits Legacy-Technologie und wird dennoch weiterhin in neuen Projekten eingesetzt
- Manche behaupten, React sei „modern“, doch tatsächlich werden damit nur Methoden der Vergangenheit wiederholt
Regel der minimalen clientseitigen Komplexität
- Serverseitiger Code ist von Entwicklern kontrollierbar, sodass Performance und Verfügbarkeit effektiv gesteuert werden können
- Clientseitiger Code läuft in vielfältigen Umgebungen, die Entwickler nicht kontrollieren können, weshalb sich Stabilität und Performance nur schwer garantieren lassen
- Die beste Strategie ist, die Menge des an den Client gesendeten Codes zu reduzieren
- HTML und CSS priorisieren, um die Abhängigkeit von JavaScript zu minimieren
- React und ähnliche Frameworks verursachen unnötige Codeduplizierung und Performance-Verluste
Was ist also die Alternative?
Eine Debatte, die sich in zwei Fragen aufteilt
- Die enge Frage: „Wenn Client-Rendering nötig ist, was sollte man statt React verwenden?“
- Moderne Frameworks sind eine Überlegung wert, etwa Svelte, Lit, FAST, Solid, Qwik, Marko, HTMX, Vue oder Stencil
- Aber auch bei diesen Frameworks müssen clientseitige Payloads und Komplexität streng kontrolliert werden. JavaScript ist gegenüber HTML/CSS mindestens dreimal so teuer
- Die breite Frage: „Wie sollte man vorgehen, wenn man einen auf React basierenden Technologie-Stack grundlegend neu bewerten will?“
- Es geht nicht nur darum, ein neues Tool einzusetzen, sondern Zweck und Grenzen der bestehenden Architektur zu verstehen und sie neu zu entwerfen
Ansatz für die enge Frage
- Mehrere kleine PoCs (Proof of Concept) erstellen, um Performance-Skalierung und Grenzen zu bewerten
- Solche objektiven Experimente liefern Teammitgliedern wertvolle Engineering-Erfahrung
Typische Situation von Teams, die die breite Frage stellen
- Diskussionen über den Ersatz von React führen oft zu Verwirrung
- Entscheidungen wurden meist getroffen, indem man der bestehenden Architektur einfach gefolgt ist
- Es fehlt an klarem Verständnis der User Experience und an datenbasierten Entscheidungen
Unterschied zwischen Framework-Ideologie und nutzerzentriertem Ansatz
- Framework-Ideologie: der Glaube, dass sich jedes Problem lösen lässt, wenn man dem Framework nur mehr Funktionen hinzufügt
- In der Praxis werden Nutzerprobleme damit oft nicht gelöst
- Ungewöhnliche Muster oder datengetriebene Belege werden ignoriert
- Realismus: User Experience messen und Entscheidungen auf realen Daten basieren lassen
- Anforderungen und Einschränkungen der Nutzer verstehen und darauf aufbauend den Technologie-Stack entwerfen
- Der Ausgangspunkt sind immer die Nutzerbedürfnisse
Wie man Realismus einführt
- RUM-Daten nutzen: nutzerzentrierte Performance-Metriken wie Core Web Vitals verwenden
- Performance-Tests: Tools wie WebPageTest (WPT) einsetzen, um wichtige Nutzerpfade (critical user journeys) zu messen
- Geschäftsziele mit User Experience verknüpfen: anhand von Daten Verbesserungsrichtungen und die Wirkung im Verhältnis zum Investitionsaufwand bewerten
Warum ein datenbasierter Ansatz wichtig ist
- Frameworks nicht auf Basis von Vertrauen einführen, sondern ihre Wirkung mit Daten verifizieren
- Tatsächliche Kosten und Nutzen einer trendgetriebenen Technologieeinführung vergleichen
- Über messbare Kennzahlen Technologieentscheidungen fördern, die auf die Optimierung der User Experience ausgerichtet sind
Nichts Wertvolles ging verloren
Wirkung von Richtlinien, die die Verbreitung von React verhindern
- Das Verbot von React und anderen frameworkzentrierten Ansätzen trägt zu Kostensenkung und zu einer Neuausrichtung von Teams auf die Nutzer bei
- Ohne die Framework-Ideologie vollständig auszuschließen, sind grundlegende Leistungsverbesserungen jedoch schwer erreichbar
- Selbst wenn man einen Fehler vermeidet, bleibt die Wirkung begrenzt, wenn man stattdessen in einen anderen Fehler derselben Kategorie investiert
Allgemeine Lösung für das breitere Problem
Nutzerzentrierung
- Entscheidungsträger müssen direkt Verantwortung für die Folgen ihrer Engineering-Entscheidungen übernehmen
- Wenn ein System für Nutzer – insbesondere benachteiligte Nutzer – nachweislich nicht gut funktioniert, muss ohne Ausreden eine alternative Version eingeführt werden
- Es gibt nur Probleme, die gelöst werden müssen; ein unkritisches Festhalten an bestehenden Ansätzen als „heilig“ ist auszuschließen
Evidenzbasierter Ansatz
- Es braucht ein gemeinsames Bekenntnis von Management und Engineering zum Realismus
- In Entscheidungen müssen bessere Belege immer Vorrang haben
Schutzmechanismen
- Es braucht Richtlinien, um die fantasievollen Versprechen der Framework-Ideologie zu verhindern
- Beispiel: die technischen Anforderungen des britischen Government Digital Service an Progressive Enhancement
- Richtlinien lassen sich an die Organisation anpassen, etwa durch Eskalationspfade für Ausnahmefälle
- Entscheidend ist jedoch die Festlegung klarer Kriterien. Evidenzbasierte Richtlinien entfalten starke Wirkung
Vergleichende Technologiebewertung
- Kein neues System ausrollen, ohne klar definierte wichtige Nutzerpfade (critical user journeys)
- Wichtige Nutzerpfade beschreiben die Aufgaben, die Nutzer in einem System am häufigsten ausführen
- Darauf aufbauend vergleichende Evaluierungen (bakeoffs) durchführen, die die Leistung jeder Technologie unter vorgegebenen Randbedingungen testen
- Produktmanager sollten nicht nur lose Experimente vorschlagen, sondern klare Produkthypothesen und Erfolgskriterien definieren
- Das kann unangenehm sein, ist aber eine Kernaufgabe von Produktmanagern
- Wenn ein PM entscheidet, dass das nicht zur eigenen Rolle passt, wird auch dessen Kündigung in Kauf genommen
Fallstudien
Unterschied zwischen Realismus und Framework-Ideologie: anhand von Beispielen
- Kriterien für Technologieentscheidungen
- Technologieentscheidungen werden anhand der Anzahl wichtiger Datenaktualisierungen und der Sitzungsdauer bewertet
- Einige App-Klassen zeichnen sich durch lange Sitzungen und häufige Datenaktualisierungen aus
- In solchen Fällen kann ein lokales Datenmodell geeignet sein
- Das sind jedoch seltene Ausnahmefälle
- Bei kurzen Sitzungen
- Websites mit kurzer durchschnittlicher Sitzungsdauer müssen die anfängliche JavaScript-Lademenge minimieren
- Die meisten Websites benötigen keine SPA-Architektur
- Wenn eine SPA-Architektur nötig ist
- Eine SPA-Architektur sollte nur dann in Betracht gezogen werden, wenn bestimmte Bedingungen erfüllt sind
- wenn Sitzungen lang sind und wiederholte Aktualisierungen derselben Daten nötig sind
- Websites, die diese Bedingungen nicht erfüllen, sollten kein SPA einsetzen
- Eine SPA-Architektur sollte nur dann in Betracht gezogen werden, wenn bestimmte Bedingungen erfüllt sind
- Die Kernfrage
- Es geht nicht um eine Wahl zwischen JavaScript-Frameworks
- In den meisten Fällen ist entscheidend, ob man überhaupt ein SPA-orientiertes Tool einsetzen sollte
- Für die meisten Websites lautet die klare Antwort „nein“
Informationswebsites (Informational)
- Optimale Struktur: semantisches HTML und bei Bedarf Progressive Enhancement
- Statische Site-Generatoren wie Hugo, Astro, 11ty oder Jekyll sind geeignet
- Für häufig aktualisierte Inhalte eignen sich CMS-Tools wie WordPress
- Blogs, Marketing-Sites, Unternehmenswebsites und öffentliche Informationsseiten sollten ihre clientseitige JavaScript-Payload so weit wie möglich reduzieren
- Es sollten keine Frameworks verwendet werden, die für SPA-Architekturen ausgelegt sind
- Warum semantisches Markup und Progressive Enhancement passend sind
- Kennzeichnend sind kurze Sitzungen und ein servereigenes Datenmodell
- Die Quelle der auf einer Seite angezeigten Daten wird immer auf dem Server verwaltet
- Eine clientseitige Datenmodell-Abstraktion oder Komponentendefinition ist nicht nötig
- CMS-Aufbau:
- ein wenig frequentierter, hochinteraktiver Editor für Autoren
- eine stark frequentierte, wenig interaktive Viewer-UI für Leser
- Kennzeichnend sind kurze Sitzungen und ein servereigenes Datenmodell
E-Commerce
- Empfohlene Architektur: servergeneriertes semantisches HTML und Progressive Enhancement
- Der Performance-Abstand zwischen Amazon und React-basierten Wettbewerbern ist deutlich
- Mehr als 70 % des Walmart-Traffics kommen von Mobilgeräten; das SPA-basierte Next.js wirkt sich negativ auf das Geschäft aus
- Warum Progressive Enhancement passt
- Typische Struktur im E-Commerce:
- Landingpages mit den aktuell angebotenen Produkten und Suchfunktionen
- Suchergebnisseiten mit Filtern und Vergleichsfunktionen
- Produktdetailseiten mit Medien, Bewertungen und empfohlenen Alternativen
- Ansichten für Warenkorbverwaltung, Checkout und Kontoverwaltung
- Servereigenes State-Management:
- frische Inhalte wie Preise erhalten
- Latenz durch Optimierung schlanker Seiten reduzieren
- aggressives Caching, Bildoptimierung und Strategien zur Verringerung der Seitengröße einsetzen
- Typische Struktur im E-Commerce:
Medienkonsum-Websites (Media)
- Grundstruktur: auf Progressive Enhancement basierend entwerfen
- Bei Bedarf entsprechend Produktänderungen Komplexität ergänzen
- Warum Progressive Enhancement und eine Islands-Architektur passen
- Interaktive Elemente wie Kommentar-Threads können als unabhängige Datenmodelle aufgebaut werden
- Mit Web Components lassen sie sich innerhalb statischer Seiten umsetzen
- Wann ein SPA geeignet ist
- Persistenz der Medienwiedergabe:
- ein Mini-Player muss bei der Navigation zwischen Seiten erhalten bleiben
- Einsatz von SPA-Technik bei gleichzeitiger Begrenzung der clientseitigen JS-Größe
- Unterstützung für Offline-Wiedergabe:
- Logik zur Verwaltung lokaler Medien-Caches ist nötig
- Datensynchronisierungssysteme wie Zero oder Y.js können in Betracht gezogen werden
- Persistenz der Medienwiedergabe:
Soziale Medien (Social)
- Hybrides Modell: geringe Interaktion auf Basis eines servereigenen Datenmodells plus gelegentliche Medienaktualisierungen
- Warum Progressive Enhancement passend ist
- Typische Interaktionen:
- auf „Gefällt mir“ klicken, gelegentliche Updates usw.
- ein hybrider Ansatz mit Hotwire oder HTMX ist geeignet
- Typische Interaktionen:
- Wann ein SPA geeignet ist
- Tief interaktive Islands:
- clientseitiges Caching etwa zum Speichern von Beitragsentwürfen
- Offline-Unterstützung:
- HTML zuerst ausliefern, Synchronisierung und Offline-Logik aber über Service Worker umsetzen
- Tief interaktive Islands:
Produktivitäts-Apps (Productivity)
- Dokumentzentrierte Produktivitäts-Apps haben komplexe Anforderungen wie kollaboratives Bearbeiten, Offline-Unterstützung und leichte Ansichtsmodi
- Ein lokales Datenmodell und eine SPA-basierte Architektur können geeignet sein
- Warum ein SPA geeignet sein kann
- Häufige Datenaktualisierungen:
- bei Eingaben, Mausziehen und ähnlichen Aktionen ist clientseitige Logik im Vorteil
- Performance-Beschränkungen müssen gemanagt werden:
- anfängliche Bundle-Größe kontrollieren
- Strategien für verzögertes Nachladen von Paketen anwenden
- Häufige Datenaktualisierungen:
Weitere Anwendungsklassen (Other Application Classes)
- Spezifische Anforderungen:
- 3D-CAD, Programmiereditoren, Game-Streaming, webbasierte Spiele, Medienbearbeitung, Musikproduktionssysteme usw.
- Jede App-Klasse muss genauso sorgfältig bewertet werden wie Produktivitäts-Apps
- Voraussetzungen für Erfolg:
- wichtige Nutzerpfade definieren
- durchschnittliche Sitzungstiefe analysieren
- Kennzahlen zur Performance-Garantie festlegen
- zentrale Skripte und Ressourcen kontrollieren
Ein Wort zu Enterprise-Software
- „Unternehmens-Business-Apps“ verursachen typischerweise die schlimmsten Performance-Probleme
- Dashboards, Workflow-Systeme und Enterprise-Chat-Apps sind typische Beispiele
- Performance ist Kultur:
- schon bei der Definition und Messung von Initial Load und Performance nach Interaktion wird versagt
- eine entwicklerzentrierte Kultur, die Nutzer ignoriert, wirkt toxisch
„Aber …“
- Manager, die an bestimmte Frameworks wie React gebunden sind, führen oft allerlei Argumente an, um diese Wahl zu rechtfertigen
- Diese Diskussionen stellen die User Experience jedoch nicht in den Mittelpunkt, und genau dieses Defizit kehrt immer wieder zurück
„…wir müssen schnell sein“
- Frage: „Wie lange wird das Ihrer Meinung nach tragen?“
- Schnell entwickelte NPM-basierte Projekte führen zu Accessibility-Problemen, schlechter Performance und wachsender Komplexität – am Ende sinkt die Geschwindigkeit
- Kosten der Nachbesserung: Das Beheben von JavaScript-Problemen dauert Monate, wodurch sich die Release-Geschwindigkeit weiter verlangsamt
- Für Product-Market Fit sollten Accessibility und Qualität Priorität haben
- Die Entscheidung, mit React „schnell zu sein“, kostet langfristig mehr und behindert Wachstum
„…bei Facebook funktioniert das doch gut“
- Die meisten Unternehmen stehen nicht vor denselben Problemen wie Facebook
- Auch Facebook leidet unter Performance-Problemen durch React, kann diese aber dank seiner dominanten Stellung überdecken
- Normale Unternehmen sollten Facebook nicht blind kopieren
„…unser Team kennt React bereits“
- React-Entwickler sind Webentwickler. CSS, HTML, JavaScript und Arbeit mit dem DOM sind unverzichtbar
- React ist im Technologie-Stack die am einfachsten austauschbare Schicht
- Es gibt keine große Hürde, kleinere und schnellere Frameworks wie Preact, Svelte, Lit oder FAST zu lernen
„…Hiring muss einfach sein“
- Die IT-Branche bietet derzeit eine ausgezeichnete Gelegenheit, starke Entwickler einzustellen
- React-Kenntnisse können kein zentrales Einstellungskriterium sein
- Entwickler, die React kennen, können in der Regel auch Webstandards leicht lernen
- Im Gegenteil liefern einfachere Systeme einen höheren ROI
„…alle haben doch schnelle Smartphones“
- Mit dem Wachstum mobiler Nutzung in den letzten zehn Jahren ist die Annahme, clientseitige Ressourcen seien billig, bereits falsch
- Nutzer mit langsamen Smartphones gehören mit hoher Wahrscheinlichkeit ebenfalls zur Kernkundschaft
- Mit der Wahl von React davon auszugehen, dass alle Nutzer teure Geräte haben, ist riskant
„…React ist der Industriestandard“
- React ist kein konsistenter Standard
- Schon innerhalb von React unterscheiden sich Projekte in Ansatz und Stack: Klassenkomponenten vs. funktionale Komponenten, Einsatz von TypeScript, Wahl des State-Management-Tools usw.
- Ein React-Stack ist ständig im Fluss, und die Behauptung eines „Standards“ ist nicht mehr als eine bequeme Fiktion
„…das Ecosystem …“
- Es gibt nur sehr wenige Libraries, die ausschließlich mit React kompatibel sind; die meisten Tools lassen sich auch mit Preact usw. verwenden
- Jedes NPM-Paket wird zu technischer Schuld gegenüber der Zukunft
- Unnötige Abhängigkeiten wie CSS-in-JS erhöhen nur die Kosten
„…Next.js ist doch schnell genug“
- Next.js bringt standardmäßig die Performance-Probleme von React mit
- HTML-first-Tools wie Astro oder 11ty liefern bessere Performance als Next.js
- Hinzu kommt das Risiko eines Lock-ins in die API eines VC-finanzierten Startups
„…React Native!“
- React Native macht mobile Apps langsamer und verursacht hohe Wartungskosten
- PWA und Capacitor/Cordova sind die bessere Wahl
- Auch Facebook entfernt sich von React Native
12 Kommentare
Normale Unternehmen sollten nicht blind dem Beispiel von Facebook folgen.
Nutzer mit leistungsschwachen Smartphones sind mit hoher Wahrscheinlichkeit ebenfalls eine wichtige Zielgruppe des Produkts.
React Native macht mobile Apps langsamer und verursacht hohe Wartungskosten.
Hahaha, hahaha
Der Text ist zu lang, dadurch verwässert die Kernthese.
Der Autor scheint die Position, man solle React verwenden, pauschal so zu verstehen, als entspringe sie ausschließlich einem Framework-Dogmatismus.
Nachdem er sagt, man solle sich vom Framework-Denken lösen und je nach Fall vorgehen, versucht er zugleich, für jede Art von Engineering-Anforderung ein Rezept zu formulieren.
Auffällig ist auch der übertriebene Versuch, die Unterhaltung zu dominieren, indem auf jeden erwartbaren Einwand geantwortet werden soll. Die Gegenargumente zu Einwänden sind dabei viel zu eng gefasst.
Mit anderen Worten: Um eine Diskussion zu führen, die über Einzelfälle hinaus allgemeine Fragen behandelt, fehlen dem Autor offenbar sowohl die nötige Diskussionshaltung als auch die Fähigkeiten.
Das Ergebnis ist, dass ich, obwohl ich den Einsatz von React selbst nicht besonders mag, allein wegen der einseitigen Haltung des Autors nun eher bereit bin, mir die Argumente derjenigen anzuhören, die für den Einsatz von React plädieren.
Persönlich denke ich derzeit, dass React nach wie vor die beste Wahl ist, daher meine Einschätzung.
Ich habe mit der Webentwicklung noch zu PHP- und jQuery-Zeiten angefangen und in meiner jetzigen Firma AngularJS, Angular, class-style React und hook-style React erlebt. Aus dieser Perspektive ist es weniger nervenaufreibend, den Technologie-Stack erst dann zu wechseln, wenn die Erfahrungen derjenigen, die ihn bereits genutzt haben, und die dazugehörigen Bibliotheken vorhanden sind. Wenn man es semantisch versioniert betrachtet, entspricht das der Nutzung der Major-Version direkt unter der neuesten. Die Anforderungen und High-Level-Features ändern sich dadurch nicht, also ist das kein Problem. Fehlen jedoch Referenzmaterialien zur zugrunde liegenden Technologie, leidet die Produktivität deutlich. Außerdem ist es aufgrund der Projektcharakteristik in unserem Unternehmen — anders als bei SaaS-Services — so, dass die Produktzyklen lang sind und es Phasen gibt, in denen nur Maintenance gemacht wird; dadurch war es umso schwieriger, die allerneueste Technologie einzusetzen.
Wahrscheinlich müsste man einen Technologiewechsel noch einmal ernsthaft in Betracht ziehen, wenn React sich vollständig in Richtung Next.js bewegt, die SPA-Unterstützung beendet und einen Architekturwechsel erzwingt. Wenn Vue etwas weiter verbreitet wäre, käme es natürlich in die engere Auswahl. Es gibt keinen Grund, es nicht zu verwenden.
Warum empfiehlt man Capacitor oder Cordova, wenn man sagt, dass RN mobile Apps langsam macht? Ich denke, dass schon allein eine native UI leistungsseitig ein deutlich besserer Ansatz ist als eine hybride Web-App.
Traurigerweise ist die Wahrscheinlichkeit sehr hoch, auf dem koreanischen Arbeitsmarkt im Bewerbungsprozess schon im Vorstellungsgespräch auszuscheiden, wenn die Haltung „Framework-Purismus funktioniert nicht“ dort nicht verfängt. In vielen Interviews werden Fragen gestellt, die man nur beantworten kann, wenn man tatsächlich viel mit Frameworks gearbeitet hat.
Als RN-Entwickler könnte ich heulen.
Wenn man es ernsthaft betrachten will, liegt die Bedeutung von RN darin, dass man native Komponenten über ein JS-Bundle steuern kann, daher sind die Use Cases im Vergleich zu PWA völlig unterschiedlich.
Es gibt Bereiche, die sich selbst mit einer WebView nur schwer handhaben lassen, und dann PWA? Langfristig wird es sich zwar wohl in diese Richtung entwickeln, aber im Moment ist das noch verfrüht. Mir kommt es so vor, als würde hier von vornherein ein bedeutungsloser Vergleich angestellt.
Stimmt. Der Haupttext vertritt fast schon die Ansicht, dass native Apps kaum nötig sind.
Solange es Menschen gibt, die sich von Neuem angezogen fühlen, wird sich diese Frage wohl wiederholen. Da es bereits Systeme gibt, die mit React aufgebaut sind, wird sich die Realität nicht ändern, wenn man das Einstellungsproblem ignoriert. Es gibt einen Unterschied zwischen den Gründen, aus denen Facebook React vorangetrieben hat, und den Gründen, aus denen gewöhnliche Unternehmen sich nach zehn Jahren für React entscheiden.
Ich denke, Diskussionen darüber, die Architektur und das Paradigma zu verändern, sollten vorsichtiger geführt werden und möglichst viele Menschen überzeugen.
Aber auch
preactist React-ähnlich, und wenn man React verlässt, ist die Zahl der Bibliotheken ...Wenn etwas wie eine brauchbare Bibliothek aussieht, ist es alles nur für React – da weint der Vue-Entwickler.
Ich nutze es zwar gut, aber es wirkt schon ein wenig wie überzogenes React-Bashing .. Wenn man es so ausschweifend aufschreibt, entsteht irgendwie der Eindruck, als solle man das Gefühl bekommen, mit einem riesigen Problem konfrontiert zu sein..
Hacker-News-Kommentare
Ich denke, dass die meisten Gründe gegen die Verwendung von React darauf hinauslaufen, die falschen Probleme lösen zu wollen. Performance-Probleme sind in Wirklichkeit kein großes Thema. In den meisten Fällen sind Verbesserungen im Backend effektiver
React und jQuery wurden populär, weil der Code sauber aussieht. Frühe AngularJS-Codebeispiele sahen nicht gut aus
Der Kern von React ist, dass sich UI-Zustand der Größe O(n) funktional rendern lässt. Früher war es komplex, Zustandsübergänge der Größe O(n^2) zu verwalten
Der Grund, React weiter zu verwenden, ist, dass es wie Java eine stabile und ausgereifte Technologie ist. Es gibt eine starke Community und viele Ressourcen
Alex’ Artikel zeigt die Frustration über eine sich ständig wiederholende Debatte. Viele Leute lesen den Artikel nicht bis zum Ende
Die Aussage, React-Entwickler seien Webentwickler, fühlt sich immer weniger zutreffend an. Es gibt immer mehr Entwickler, die nur mit SPA-React und Styling-Frameworks vertraut sind
Die meisten Websites brauchen kein SPA. Aber für Unternehmen, die viele Daten benötigen, ist ein SPA von Vorteil
Ich mag React nicht. Als hauptsächlich Backend-Entwickler bevorzuge ich serverseitig erzeugtes HTML und ein wenig JavaScript
Der Grund, warum sich Frontend-Entwicklung zu JavaScript-Frameworks bewegt, sind die Wartungskosten
Es gibt viel unzutreffende Kritik an React. React-Entwickler erledigen ihre Arbeit, ohne eine neue Template-Sprache zu erfinden