Gibt es überhaupt jemanden, der React wirklich mag?

 (jsx.lol)
1 Punkte von GN⁺ 4 시간 전 | 3 Kommentare | Auf WhatsApp teilen
  • Eine kuratierte Sammlung von kritischen Texten über React und React-nahe Tools, die Beiträge verschiedener Entwickler und Blogger in Form von Zitaten zusammenstellt
  • Enthält zahlreiche Texte, die auf strukturelle Grenzen von React hinweisen, etwa Leistungseinbußen, steigende Komplexität und Hydration-Probleme
  • Die technische Entscheidung zugunsten von React habe sich eher durch Trägheit und Netzwerkeffekte als durch technische Eignung verfestigt; kritisiert wird, dass die Annahme „alle kennen React“ Architekturentscheidungen vorausgeht
  • Rund um React Server Components und Next.js sind Sicherheits- und Governance-Bedenken gewachsen; CVE-2025-55182 wurde als unauthenticated Remote-Code-Execution-Schwachstelle mit CVSS 10.0 veröffentlicht
  • Die Verwirrung in der API-Gestaltung des React-Ökosystems, die Qualitätskrise und die Komplexität erschweren langfristige Wartung und Lernen und führen bis hin zu Debatten über Hooks, moderne UI-Funktionen und den Release-Kurs von React

Überblick über die Website

  • Eine kuratierte Website mit der provokanten Frage „Does anybody actually like React?“
  • Eine cherry-picked Sammlung kritischer Texte über React und von React beeinflusste Tools
  • Bietet eine RSS-Abonnementfunktion

Grundlegende Kritik an React selbst

Sicherheits- und Governance-Probleme

Probleme bei API-Design und Lernkurve

  • Is it Time to Regulate React?

    • Reacts zentrales Scheitern werde durch ein verwirrendes API-Design verstärkt
    • Die Dokumentation sei unentschlossen, und Debatten über die richtige Nutzung nähmen kein Ende

  • I don't have time to learn React

    • Entgegen der Behauptung, React lehre moderne UI, könne es mit moderner UI in der Praxis kaum umgehen
    • autofocus ist kaputt, und custom elements funktionieren außerhalb experimenteller Versionen nicht
    • Für moderne Funktionen wie dialog oder popover sei useEffect nötig
    • Wegen des synthetic event-Systems lerne man fast nichts über das tatsächliche DOM-Verhalten
    • Keine moderne UI, sondern eine UI auf dem Stand von 2013

  • The React Blog Post: Reflections and Reactions

    • Es wirke seltsam, alle Probleme als „skill issue“ abzutun und zu behaupten, sie ließen sich mit externen Bibliotheken lösen
    • Technologie sollte so beschaffen sein, dass man auch nach drei Jahren zurückkehren und weiterarbeiten kann, doch im Frontend, besonders bei React, sei das nicht so

  • React, where are you going?

    • Zwei Probleme, die React heute weniger angenehm machen: ownership und complexity
    • Es gibt die Sorge, dass neue Entwickler sich von React eingeschüchtert fühlen könnten

Probleme bei Leistung und Nutzererfahrung

  • Why use React?

    • Man gerate im Grunde in das berüchtigte Hydration-Muster
    • Die Struktur: Alle Berechnungen werden serverseitig in JS ausgeführt, HTML wird sofort ausgeliefert, und anschließend wird dasselbe JS noch einmal an den Client gesendet

  • How React 19 (Almost) Made the Internet Slower

    • Nach öffentlichem Widerstand und heftigen Debatten stellte das React-Team die Änderung zurück

  • An even faster Microsoft Edge

    • Wechsel von React zu modernen Web Components + HTML-first-Architektur
    • Besonders Nutzer mit leistungsschwacher Hardware profitieren deutlich

  • Switching costs

    • Der Wunsch nach mehr Beschwerden über die von clientseitigem React erzwungene schreckliche Nutzererfahrung
    • Tatsächlich konzentriere sich die Kritik aber fast nur auf die Developer Experience

  • Pivoting From React to Native DOM APIs: A Real World Example

    • Ein Entwicklerteam wechselte vom „überwältigenden VDOM“ von React zu modernen DOM-APIs
    • Geschwindigkeit und Interaktionen hätten sich sofort spürbar verbessert

Mobile und Plattform-Probleme

Probleme im Ökosystem und in der Community

Kritik an React Server Components

Rückkehr zu den Grundlagen und Betonung von Alternativen

Migrations- und Wechselbeispiele

Gesamttrend und Ausblick

Hooks und alternative Paradigmen

  • Why Signals Are Better Than React Hooks

    • Die Hooks von React sind schwer korrekt einzusetzen, und performant zu nutzen ist noch schwieriger
    • Ursache für nachlassende Codequalität und Performance in vielen Anwendungen

Bildhafte Kritik

  • What Is React.js?

    • Ein Video, das die Eigenheiten der Befürworter, übertriebene Selbsternsthaftigkeit und endlose Dokumentation mit dem Christentum vergleicht

Verwandte Beiträge

3 Kommentare

 
bichi 6 분 전

React ist einfach nur ein Glaube (eine Sekte)
 
bichi 5 분 전

So ähnlich wie Ant Mill //
 
GN⁺ 4 시간 전
Hacker-News-Kommentare

  • Es gibt Dinge, die mir an React nicht gefallen. React ist ein Framework, um interaktives HTML auf den Bildschirm zu bringen, nicht um extrem komplexe Programmierung zu betreiben.
    Erstens stützt es sich zu sehr auf komplexe Konzepte und Terminologie. Im Vergleich zu Vue entspricht useEffect watch, und useMemo entspricht computed.
    Zweitens hat sich diese unnötig „clevere“ Herangehensweise über die Terminologie hinaus auch ins Ökosystem eingeschlichen. Früher musste man bei Redux für das Erhöhen einer einzelnen Zahl über mehrere Dateien hinweg viel Code schreiben, und es wirkte, als läge das daran, dass der Autor ausgefuchste Informatik-Konzepte mochte. Zur gleichen Zeit konnte man in VueX diese Zahl einfach erhöhen. Zum Glück gibt es im heutigen React-Ökosystem viele vernünftige State-Manager.
    Drittens bringt React keine Werkzeuge für die Arbeit mit CSS von Haus aus mit.
    Viertens optimiert React nicht automatisch für einen. Man muss wissen, wann und wie man useEffect und useMemo einsetzen oder eben nicht einsetzen sollte, und es gibt jede Menge Folklore rund um React-Optimierung. Das ist problematisch, obwohl Re-Rendering doch ein zentrales Ziel ist. In Vue zwingt das Framework einen dazu, seine eigenen Werkzeuge zu verwenden, und optimiert innerhalb dieses Rahmens das meiste, sodass ich bei einer Vue-App noch nie gedacht habe, ich müsste sie manuell optimieren.
    Fünftens ist diese Folklore selbst ein Problem. Die React-API und die „richtige Art, React zu schreiben“ haben sich viel zu oft und zu stark geändert, sodass es selbst heute sehr schwer ist, richtige von falschen Aussagen zu unterscheiden.
    Am Ende lässt sich React so zusammenfassen: zu starker Fokus auf Ideen, Informatik und Abstraktionen auf hohem Niveau, und zu wenig Fokus darauf, tatsächlich leicht interaktives HTML auf den Bildschirm zu bringen.
    Ich nutze React, Vue und Svelte alle viel, aber wenn ich React benutze, muss ich mich ständig um Dinge kümmern, die Vue oder Svelte schon erledigt hätten. Leistungsmäßig sind die drei ähnlich.
    Ich habe dazu früher auch etwas geschrieben: https://www.brachkow.com/notes/what-i-like-in-vue/

  • Als jemand, der in den letzten etwa 16 Jahren alle großen Strömungen von JavaScript mitgemacht hat, mag ich React in gewisser Weise.
    React ist von allen JavaScript-Frameworks, die wir ausprobiert haben, das schlechteste — abgesehen von allen anderen.
    Gegenüber der Angular-1-Zeit würde ich jederzeit React wählen. Lieber das schwergewichtige MVC von Angular 1 als die Art von Backbone, bei der man jedes Mal alles von Grund auf selbst zusammensetzt, und die minimale MVC-Struktur von Backbone war besser als die klassische JQuery-Suppenarchitektur. Gegenüber den nativen APIs von damals hätte ich sofort JQuerys DOM-Manipulation und die Ergänzung der Standardbibliothek gewählt.
    React hat seine Trade-offs, aber wir sind erst hier gelandet, nachdem wir lange viele Alternativen erlebt haben, die nicht funktioniert haben.

    • Ich nutze React gern und würde es gegenüber dem wählen, was vorher da war. Aber wenn das alles ist, was man braucht, würde ich htmx/data-star mit Server-Rendering React nicht vorziehen, und auch dann nicht, wenn es ein paar etwas komplexere Seiten gibt.
    • Ich verstehe allerdings nicht, warum man React statt Vue nehmen würde. Das Frustrierendste war für mich immer, dass Vue sich am Ende in Richtung React bewegt. Vues ursprüngliche Komponentenstruktur, also HTML-Templates, JavaScript-State und CSS-Stile zusammen an einem Ort, war wirklich gut. Auch die Art, innerhalb einer Komponente Daten per URL zu laden, war sehr intuitiv.
    • Stimme zu. Ich bin von handgeschriebenem cgi-bin-HTML über JQuery und Angular v1 zu React gekommen, und React ist ein Werkzeug, das ich bereitwillig in die Hand nehme. Es erledigt, was ich erledigen will.
    • React ist besser als Angular, und Vue ist besser als React.
    • Mich würde interessieren, ob du Svelte ausprobiert hast. Ich verstehe nicht so recht, warum jemand React lieber mögen könnte. Der einzige Vorteil von React ist aus meiner Sicht, dass es so etwas wie das IBM des Frontends ist. Niemand wurde gefeuert, weil er sich für React entschieden hat.

  • Natürlich gibt es Leute, die React mögen. Es ist nicht wie JavaScript, das man faktisch zwangsweise verwenden muss, und auch React oder ein anderes Web-Framework werden einem nicht zwingend aufgezwungen, trotzdem hat React gewonnen. Das kann man zumindest als Beleg dafür sehen, dass es von den meisten Leuten deutlich mehr gemocht wird als die meisten anderen Frameworks.
    Bis in die späten 2010er war eine häufige Beschwerde über Webentwicklung, dass sich alles zu schnell ändere und ständig Neues zu lernen sei, und diese Beschwerde war berechtigt. Aber jetzt, wo die React-Monokultur an der Spitze steht, beschweren sich alle darüber, dass genau das ihnen nicht gefällt. Man kann es wirklich niemandem recht machen.

    • Im Job konnte ich mir Frameworks und Bibliotheken fast nie aussuchen. Fast immer habe ich etwas übernommen, das jemand vor Jahren angefangen hatte, oder ich war in einer Organisation mit streng vorgegebenen Optionen gebunden. Privat würde ich React nicht wählen.
      React hat gewonnen, weil es zur Standardwahl geworden ist und Menschen das bevorzugen, womit sie vertraut sind.
    • React hat Vorteile, aber oft wird es eher wegen Trägheit gewählt als weil es das beste Werkzeug für die Aufgabe ist. Gründe wie „Alle nutzen React, also maximieren wir den Hiring-Pool und den Pool an Dienstleistern“ oder „Ein React-Projekt sieht gut im Lebenslauf aus“ spielen dabei mit hinein.
    • Eher wird man gezwungen, React und Next.js zu verwenden. Viele SaaS-Anbieter kooperieren mit Vercel und öffnen Erweiterungspunkte nur in diese Richtung.
      Wenn man etwas anderes verwenden will, muss man Integrationen selbst bauen, ein bereits vorhandenes Open-Source-Projekt finden oder eine KI fragen.
      Für Hobbyprojekte geht das, aber im Arbeitsumfeld ist das schwer vorstellbar.
    • Ich verstehe nicht, was damit gemeint ist, dass niemand gezwungen wird, React zu verwenden. Wo ist diese schöne neue Welt, in der man Lisp lernen und für alles einsetzen kann, was man will, und in der Unternehmenskultur keinerlei Einfluss auf die Technologiewahl hat?

  • Ich mag React. Ich habe auch das HTMX-/Hotwire-Lager ernsthaft ausprobiert.
    Ich wollte einen Zurück-Button bauen, der bei Aufruf aus dem Posteingang per Browser-API zurückgeht, andernfalls aber zum Posteingangs-Link führt, um die Scroll-Position zu erhalten. Ich musste das Verhalten im HTML verdrahten, eine Zurück-Funktion aufrufen und im Controller die vorherige Seite bestimmen, um dann entweder einen per JavaScript aktivierten Zurück-Button oder einen harten Link auszuliefern. Die Logik war auf drei Dateien verteilt.
    In React kann das JavaScript im Component selbst feststellen, ob die vorherige Seite der Posteingang war, und je nach Wert den JSX-Zurück-Button oder einen Link anzeigen. Alles bleibt in einer Datei. Für mich modelliere ich damit eine konzeptionelle Einheit, während ich in anderen Ansätzen Funktionalität gewaltsam in drei Einheiten pressen muss.
    Ist es langsamer? Definitiv. Trotzdem macht es mich glücklicher. Wenn du unter der chaotischen React-Codebasis deiner Firma leidest, solltest du deine Kollegen verantwortlich machen. Ohne React wäre es sicher noch schlimmer gewesen.

    • Deshalb mag ich React-Single-Page-Apps nicht. Sie scheinen immer irgendeinen dummen Weg zu finden, die Zurück- und Navigationsschaltflächen des Browsers kaputtzumachen.
      Abgesehen von gelegentlicher Formular-Verbesserung würde ich immer htmx/Server-Rendering und natives Verhalten bevorzugen.
    • Ich finde, HTMX sollte man nur für Dinge verwenden, die mit Datenzustand zu tun haben. Etwas wie ein intelligenter Zurück-Button, das nicht vom Ressourcenstatus abhängt, sollte man lieber nicht im Backend berechnen.
      Im empfohlenen htmx-Stil würde man einen onclick-Button an Inline-JavaScript binden oder, wenn man das nicht mag, eine Funktion wie goBackOrInbox aufrufen.
      function goBackOrInbox() { if (document.referrer) { const path = new URL(document.referrer).pathname; if (path.startsWith('/inbox')) { history.back(); return; } } window.location.href = '/inbox'; }
      Wenn man dieses Muster oft verwendet, kann man es parametrisieren, indem man den Zielpfad als Argument übergibt.
    • Der beste Weg, das Zurück-Button-Problem zu lösen, ist wohl, es nicht zu kompliziert zu machen und sicherzustellen, dass nur das, wohin man wirklich zurückkehren möchte, in den Browser-Verlauf gelangt. Die Problemstellung selbst scheint geradezu zu schreien: „Wenn man die Struktur besser aufsetzt, wird daraus ein Problem, das gar nicht gelöst werden muss.“
    • Es gibt sicher hier und da komplizierte Stellen, aber ich denke, das müsste doch auch mit Web Components gehen.

  • Ich habe lange mit React-Code gearbeitet und arbeite jetzt in der Firma an einem großen Vue-Projekt. Früher hieß es immer, Vue sei von beiden die einfachere und zugänglichere Wahl, aber inzwischen sehe ich das anders.
    React ist auf elegante Weise im Wesentlichen nur: Components sind Funktionen, und darüber hinaus gibt es nicht viel. Wenn man das Next.js-Ökosystem einmal ausklammert, ist es das Eleganteste, was ich im Frontend je gesehen habe.
    Vue hingegen wirkt auf mich vermischt. Man sieht die Spuren davon, dass Backend-Entwickler, die JavaScript nicht wirklich lernen wollten, es angenommen und gefeiert haben, und das Ergebnis fühlt sich an wie eine unbeholfene Mischung, die nicht sauber zusammenpasst.

    • Diese Sichtweise habe ich nie ganz verstanden. React-Components sind nicht einfach nur Funktionen, sondern Funktionen mit einem magisch injizierten Kontext, auf den man über Hooks zugreift. Diese Hooks verlangen allerlei Garantien, und wenn man sie nicht bewusst im Blick behält, entstehen schwer zu debuggende Ergebnisse. Von Eleganz ist das für mich weit entfernt.
      Ich habe alle großen Frameworks verwendet und baue aktuell eine große Angular-Web-App. In Angular werden Components als Klassen mit Template und Styles ausgedrückt. Event-Listener rufen in der Regel Methoden der Klasse auf, und Zustand kann so einfach wie Eigenschaften der Klasse sein. Das fühlt sich viel natürlicher an und hat deutlich weniger Fallstricke. Natürlich nicht null.
    • Mich würde interessieren, wie lange du Vue schon benutzt. Ich hatte vor ein paar Jahren mit React-Hintergrund beim Blick auf Vue ähnliche Gedanken. Inzwischen bevorzuge ich Vue gegenüber React und greife sowohl bei privaten als auch beruflichen Projekten zuerst zu Vue.
      Es fühlt sich etwas anders an. Manche Dinge sind in React einfacher, andere in Vue, aber dass Vue Signals verwendet, ist für mich ein großer Vorteil.

  • Mich interessiert weniger React selbst als allgemeiner die Frage, wie man UI am besten in Code schreibt
    Ich bin React-Fan und verwende React für fast jede Webanwendung, die ich baue, aber das größte und offensichtlichste Problem ist, dass sich das Schreiben von UI mit React nicht so natürlich anfühlt wie das Schreiben von Kommandozeilen-Tools in Go oder Echtzeit-Apps in Elixir
    Manche Sprachen fühlen sich für bestimmte Aufgaben erstaunlich natürlich und reibungslos an. Aber UI hat bisher noch niemand wirklich gemeistert. Swift, JSX/HTML, Svelte oder was auch immer gerade das beliebte Framework dieser Art ist, fühlen sich alle so an, als würden sie das Problem nur irgendwie umschiffen. Es wirkt, als hätten Sprach-/Framework-Designer irgendwann schmutzige, seltsame oder schmerzhafte Syntax-Kompromisse eingebaut, um die Anforderungen irgendwie zu erfüllen
    Die natürliche Schnittstelle für UI ist visuell, deshalb könnten Werkzeuge wie Figma ein wichtiger Teil der Lösung sein. Trotzdem fühlt es sich an, als würde noch etwas fehlen. Es müsste eine intuitivere Art geben, visuelle Dinge in Code auszudrücken. Die aktuellen Lösungen sind schwer genau zu beschreiben, aber sie wirken immer so, als würden sie knapp an etwas Wesentlichem vorbeigehen

    • Empfinde ich ähnlich. Als React erschien, fühlte es sich im Vergleich zu den damaligen Alternativen perfekt an, deshalb mochte ich es wirklich sehr
      Ich bevorzuge React auch heute noch gegenüber fast allem, einschließlich Svelte, Vue und Solid. In letzter Zeit habe ich aber angefangen, Crank(https://crank.js.org/) zu verwenden, und das scheint einen Schritt näher an die Richtung zu kommen, in die ich möchte. Bisher habe ich es allerdings nur in Spielzeugprojekten ausprobiert, daher ist schwer zu sagen, wie gut es sowohl bei Performance als auch Developer Experience skaliert
    • Ich stimme der Aussage stark zu, dass „manche Sprachen für bestimmte Aufgaben erstaunlich natürlich und reibungslos sind, aber UI bisher noch niemand wirklich gemeistert hat“. Wenn man Bücher[1] aus den frühen 90ern zu diesem Problem liest, gilt das heute noch genauso
      Die beste Analyse, die ich bisher gesehen habe, steht in Chattys „Programs = Data + Algorithms + Architecture: consequences for interactive software engineering“[2]. Es ist etwas schwer zu lesen, aber absolut lohnenswert
      Kurz gesagt ist das Problem die Architektur, genauer gesagt die Diskrepanz zwischen Sprache und Architektur. Der Aufruf-/Rückgabe-Architekturstil, zu dem „Allzweck“-Programmiersprachen verleiten, passt nicht zu der Architektur, die Benutzeroberflächen brauchen, sondern steht sogar im Widerspruch zu ihr
      Darüber habe ich auch in „Can Programmers Escape the Gentle Tyranny of call/return?“ geschrieben
      Der aktuelle Ansatz ist, zuerst mit Objective-Smalltalk[4] eine Programmiersprache zu schaffen, mit der sich alternative Architekturstile leicht ausdrücken lassen
      Damit baue ich gerade ein UI-Framework namens interscript, einschließlich HTMXNative und verschiedener Ergänzungen
      Es scheint ziemlich gut aufzugehen
      [1] z. B. Myers et al., „Languages for developing user interfaces“ https://api.taylorfrancis.com/content/books/mono/download?id...
      [2] https://opendl.ifip-tc6.org/db/conf/ehci/ehci2007/Chatty07.p...
      [3] https://2020.programming-conference.org/details/salon-2020-p...
      [4] https://objective.st
    • Als Ingenieur neigt man dazu, jedes Problem anzusehen und zu denken: „Es gibt eine perfekte Lösung, wir haben sie nur noch nicht gefunden“
      Mit der Zeit akzeptiert man aber weniger idealistische Antworten. Vielleicht gibt es so eine Lösung gar nicht. Vielleicht ist der Problemraum so komplex, dass es keine für Menschen praktikable allgemeine Lösung gibt, die alle Formen abdeckt. Wenn das auf irgendeinen Bereich zutrifft, dann wahrscheinlich auf UI

  • Stimmt. React ist mit Abstand die intuitivste Oberfläche, die deklarative und imperative Stile erfolgreich kombiniert. Unter allen UI-Frameworks aller Sprachen kommt meiner Meinung nach nichts an JSX heran

    • Viele andere Plattformen wie Flutter, SwiftUI und Jetpack Compose haben React inzwischen als Vorbild für ihre eigenen UI-Frameworks umgesetzt
    • Wenn es so intuitiv ist, weiß ich nicht, warum fast jede React-App Performance-Bugs enthält

  • Ich mag Svelte wirklich sehr und verwende für komplexere Apps SvelteKit
    In vielen Fällen, in denen ich früher React verwendet hätte, fühlte es sich wie eine deutlich bessere Verbesserung an
    Svelte scheint für Leute, die die Grundlagen von Webentwicklung, HTML, CSS und JavaScript kennen, viel leichter zu lernen zu sein. Trotzdem sehe ich heute oft Leute, die mit React in die Webentwicklung einsteigen, und das wirkt irgendwie wie die falsche Reihenfolge
    Persönlich baue ich mobile Apps mit SvelteKit + Capacitor, und meine Einrichtung habe ich hier beschrieben: https://bryanhogan.com/blog/web-to-app-sveltekit-capacitor
    Für einfache Landingpages bevorzuge ich Astro

    • Ich greife auch immer zuerst zu Svelte + SvelteKit. Kit für einfache Apps zu verwenden kann übertrieben sein, aber wenn es unerwartet komplex wird, ist es gut, es schon dabeizuhaben
      Ich stimme zu, dass es verkehrt herum wirkt, wenn Leute heute mit React in die Webentwicklung einsteigen. Svelte behandelt HTML wie eine Muttersprache und verhindert dieses Problem sehr gut. Wenn man mit Svelte(Kit) in die Webentwicklung einsteigt, lernt man wahrscheinlich mehr Grundlagen als beim Einstieg mit React
    • Für mich passt die Kombination Svelte + Astro. Sie ist großartig für Dokumentationsseiten und Seiten mit optionaler Interaktivität

  • Ich war anfangs einer der Leute, die React überhaupt erst möglich gemacht haben, also bin ich voreingenommen, aber ich mag React wirklich sehr. Davor habe ich alles Mögliche ausprobiert, um die Probleme zu beheben, die ich im Frontend hatte. Aber seit React erschienen ist, musste ich das nicht mehr und konnte mich einfach aufs Bauen konzentrieren

  • Einer der Vorträge, die ich wirklich gut fand, ist https://www.youtube.com/watch?v=h9SDuTSy7ps. Meiner Erfahrung nach ist die Architektur von React wirklich gut und ziemlich gut dafür geeignet, große Anwendungen zu bauen
    Leider ist das größte Problem von React, dass es einen dazu zwingt, in das JS/TS-Ökosystem einzusteigen. Für mich ist JavaScript/TypeScript ohne jeden Zweifel eher ein Kompilierungsziel als ein System, mit dem ich direkt arbeiten möchte
    Mit Elm bin ich zufrieden. Die Community ist wirklich klein, und manchmal muss man Bibliotheken selbst schreiben. TEA wirkt aus der Perspektive von React kommend gelegentlich etwas unnatürlich, aber weil ich mir keine Sorgen um impliziten und unerwarteten Zustand wie bei useEffect machen muss, arbeite ich immer gern mit Elm
    Außerdem scheint Claude zumindest in großen und furchteinflößenden Codebasen mit Elm besser klarzukommen als mit React

    • Meiner Erfahrung nach ist Elm praktisch tot. Es ist wahrscheinlich besser, React und TypeScript zu verwenden, wo es Bibliotheken gibt, die weiterhin funktionieren. Es gab auch Versuche, TypeScript nativ kompilierbar zu machen
    • Ich mag TEA, aber ich habe nie ganz verstanden, wie es sich in Apps mit wiederverwendbaren Komponenten oder ausreichend komplexen Seiten skaliert. Ich frage mich, ob es dafür eine etablierte Vorgehensweise gibt
      Zustand scheint ein großes Tabu zu sein, daher wirkt das etwas widersprüchlich. Ich frage mich auch, ob das bedeutet, dass jede Elm-App letztlich zu einer globalen Redux- + React-App ohne Effekte wird. Ich würde gern genauer verstehen, was an Elm Spaß macht und wie man damit arbeitet. Links sind auch willkommen