React: Zehn Jahre "Rethinking Best Practices"

Inhaltsverzeichnis

"Eine JavaScript-Bibliothek, um Benutzeroberflächen zu entwickeln", lautete das schlichte Motto, als React im Mai 2013 das Licht der Open-Source-Welt erblickte. Heute – zehn Jahre später – ist sie aus dem Alltag vieler Entwicklerinnen und Entwickler nicht mehr wegzudenken. React gilt als eine der am weitesten verbreiteten Bibliotheken zum Entwickeln von Single-Page-Anwendungen (SPA). Nicht nur Facebook respektive dessen Mutterkonzern Meta, die React entwickelt und als Open Source veröffentlicht haben, nutzen diese Bibliothek, sondern auch viele bekannte Produkte wie Jira, Figma, Microsoft Outlook und Teams werden damit entwickelt.

Bewährte Praktiken immer wieder neu überdenken

React machte viele Dinge anders, als man es damals von etablierten UI-Bibliotheken für das Web und den Desktop kannte – und das gilt bis heute. Für diesen alternativen Ansatz prägte Pete Hunt, React-Entwickler der ersten Stunde, in einem Vortrag auf der JSConf 2013 den noch immer zutreffenden Leitsatz: "Rethinking Best Practices" (siehe Video). So ist denn die Geschichte der Bibliothek von einigen grundlegenden Veränderungen bewährter Praktiken geprägt. Hielten im Zuge von ECMAScript 6 etwa Klassen auch Einzug in React, ließ das Entwicklungsteam wenige Jahre später die Hooks-API folgen, die es möglich machte, React-Komponenten allein mit JavaScript-Funktionen zu entwickeln. In jüngster Vergangenheit deutet sich nun eine Abkehr von Client-seitigen Single Page Applications (SPA) an, hin zu kompletten React-Anwendungen, die zur Laufzeit einen JavaScript-Server benötigen – und daher bevorzugt mit Fullstack-Frameworks erstellt werden sollten.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

JavaScript und sonst nichts

Historisch betrachtet war das React-Team stets darauf bedacht, technische Brüche (Breaking Changes), wie sie etwa durch das Kombinieren unterschiedlicher Programmier- und Template-Sprachen auftreten, zu vermeiden: Komponenten werden daher ausschließlich mit JavaScript geschrieben. Eine Template-Sprache, wie in vielen UI-Bibliotheken üblich, gibt es nicht. Stattdessen bringt React die JavaScript-Spracherweiterung JSX mit. Diese Erweiterung ermöglicht es, XML-Code direkt in den JavaScript-Code zu schreiben. Ein Compiler sorgt im Build-Prozess dafür, dass daraus gültiger JavaScript-Code entsteht, den Browser verstehen können. Der Gedanke dahinter: Setzen Entwicklerinnen und Entwickler eine JavaScript-Bibliothek zum Bauen von Oberflächen ein, müssen sie die Sprache JavaScript ohnehin kennen oder lernen. Statt eine zweite (Template-)Sprache erlernen zu müssen, können sie auf JavaScript-Erweiterungen zurückgreifen. Nach dem Verständnis des React-Teams ist JSX demnach auch keine Template-Sprache, sondern lediglich "syntaktischer Zucker" für JavaScript. In der aktuellen React-Dokumentation heißt es sogar ganz unbescheiden: "Learning React is learning programming."

Auch populäre Architekturmuster wie das MVC-Pattern (Model View Controller) sucht man in React vergebens. Auf die Trennung in technische Einzelteile ("Separation of Concerns"), also beispielsweise in Model, View und Controller, verzichtet React bewusst und konzentriert alles, was zu einer Komponente gehört, direkt in dieser Komponente. Auf diese Weise soll Code, der fachlich zusammengehört, auch zusammenbleiben und nicht "künstlich" auf mehrere Stellen verteilt werden. Dem liegt die Annahme zugrunde, dass Änderungen oder Erweiterungen von Komponenten ohnehin nicht nur Anpassungen an der UI-, Model- oder Logik-Schicht nach sich ziehen, sondern in der Regel alle Schichten von den Änderungen betroffen sind, sodass lästiges Hin- und Herspringen zwischen den einzelnen Teilen einer Komponente die Folge ist. Außerdem sind die einzelnen technischen Bestandteile einer Komponente in der Regel nicht in anderen Komponenten wiederverwendbar, sodass auch aus diesem Grund eine Aufteilung sinnlos erscheint. Folglich war in React – bis zur Einführung der Hooks-API – die gesamte Komponente die einzige wiederverwendbare Einheit.

Bis heute unverändert geblieben ist die Tatsache, dass sich bei der Entwicklung von React-Anwendungen viel um den optimalen Einsatz des State (Zustands) von Komponenten dreht. Dabei handelt es sich um veränderliche komponenteninterne Daten, etwa den aktuellen Inhalt eines Eingabefeldes. Werden diese Daten geändert, löst React das Neurendern der Komponente aus, deren Zustand verändert wurde – einschließlich aller darunter angesiedelter Komponenten. In React gibt es kein Zwei-Wege-Databinding, also die Möglichkeit, automatisch Änderungen an der Oberfläche (etwa nach der Eingabe in ein Textfeld) in das Model beziehungsweise den Zustand einer Komponente zu übertragen. Die gewünschte Reaktion auf solche Änderungen, die in der Regel durch Ereignisse ausgelöst werden (Textfeld wurde verändert, Checkbox angeklickt, Daten vom Server sind eingetroffen ...), sind in React in der Komponente explizit zu programmieren. Der Lebenszyklus einer Komponente in React ist daher bis heute denkbar einfach: Nach dem initialen Rendern liefert die Komponente das gewünschte UI zurück. An den zurückgelieferten UI-Elementen können Event-Listener gesetzt sein. Tritt ein Event auf, kann die Komponente das Ereignis (Textfeld wurde geändert) verarbeiten und den internen Zustand aktualisieren. Als Folge rendert React die Komponente neu und der Kreislauf beginnt von vorn.

Heise-Konferenz: enterJS 2023

Am 21. und 22. Juni 2023 richten die Veranstalter dpunkt.verlag, heise Developer und iX die Enterprise-JavaScript-Konferenz enterJS in Darmstadt aus. In über 35 Vorträgen kommen JavaScript- und TypeScript-Sprachneuerungen, neue und etablierte Tools und Frameworks – darunter React, SvelteKit und Astro – sowie Barrierefreiheit und Softwarearchitektur zur Sprache.

Ganztägige Workshops stehen sowohl vor Ort als auch online bereit.

Auszug aus dem Programm:

• React 2023 – Beginn einer neuen Ära?
• Tomorrow.js? 2023.js? Was wird das nächste große Framework?
• React-Apps mit Next.js bauen (Workshop, 20. Juni, Darmstadt)
• React Beyond the Basics (Workshop, 28. Juni, online)

Single Point of Truth: Der Zustand einer Komponente

Die Übergabe von Daten zwischen Komponenten erfolgt in React stets von oben nach unten, also von höherliegenden Komponenten zu tieferliegenden. Man spricht daher in React auch vom Unidirectional Dataflow: die Daten fließen immer nur in einer Richtung durch das System. In anderen UI-Architekturen ist es weitverbreitet, dass sich Komponenten auch untereinander kennen – gegebenenfalls separiert etwa durch einen Controller – und einander per Listener über Änderungen informieren oder informieren lassen. Problematisch kann bei dieser Architektur sein, dass nicht unbedingt immer klar ist, wann sich auf welchem Weg welche Daten verändern: Welche Listener reagieren wann auf welche Veränderung? Welche Veränderung löst dann erneut Event-Handler aus? Im schlimmsten Fall kommt es dadurch zu Event-Kaskaden oder "Event-Stürmen", die die Oberfläche unnötig langsam machen.

React wirkt diesem Problem mit dem unidirektionalen Datenfluss entgegen: Es gibt nur genau eine Quelle der Wahrheit und das ist der Zustand einer Komponente. Dieser Ansatz führt allerdings dazu, dass ein Zustand, den viele Komponenten nutzen müssen, in der Komponenten-Hierarchie immer weiter nach oben wandert. In React ist dabei vom Prinzip des "Lifting State up" die Rede.

Während dieses Muster zum Verständnis von Anwendungen sehr hilfreich ist und auch typische Inkonsistenzprobleme vermeiden kann, birgt es auch einen Nachteil: Durch das "Hochschieben" des Zustands in höher angesiedelten Komponenten können schnell sehr komplexe Komponenten entstehen, deren Zustand und Logik überladen sind. Die tiefer angesiedelten Komponenten verkümmern dann zu reinen Darstellungskomponenten. Letztere sind unproblematisch, da sie leicht testbar und möglicherweise auch einfach wiederverwendbar sind, die komplexen "Gott-Komponenten" an der Spitze der Hierarchie hingegen, stellen eine Herausforderung dar. Sie können sich aus mehreren Gründen als Flaschenhals erweisen: Zum einen sind sie schwer testbar, zum anderen schränken sie die Skalierbarkeit des Entwicklungsansatzes ein. Denn im schlimmsten Fall bündeln sich mehrere Fachlichkeiten in einer Komponente, sodass gegebenenfalls auch noch verschiedene Teams daran entwickeln müssen.

Alles im Fluss

Mit der Vorstellung des Architekturmusters Flux hat sich das React-Team 2014 dieses Problems angenommen. Die Idee von Flux ist es, die (clientseitigen) Daten einer Anwendung komplett aus der Komponentenhierarchie herauszulösen und in einen Store zu überführen. Eine Komponente kann nun fachliche Actions auslösen, die vom Store interpretiert und zu Änderungen an den Daten dieses Stores führen. Auf der anderen Seite können sich Komponenten an dem Store als Listener anmelden, um sich über Änderungen informieren zu lassen. Der unidirektionale Datenfluss bleibt damit erhalten, weil die Daten immer aus einer Komponente in den zentralen Store fließen und von dort zu den interessierten Komponenten gelangen.

Gab es anfangs eine ganze Reihe unterschiedlicher Implementierungen des Flux-Architekturmusters, hat sich im Laufe der Zeit nur eine durchgesetzt, die Flux auf eine sehr eigene Art und Weise interpretiert: Redux.

Dan Abramov hatte Redux 2015 in seinem Vortrag auf der React Europe Conf in Paris vorgestellt (siehe Video). Danach avancierte Redux schnell zum Standard-Repertoire in vielen React-Anwendungen. Angesichts seiner eher speziellen API scheiden sich die Geister bei Redux – es wird gleichermaßen geliebt und gefürchtet. Fans sind unter anderem vom sogenannten Time Travelling Debugger begeistert. Die Redux Devtools können alle Änderungen an den im Store hinterlegten Daten aufzeichnen und wiederherstellen. Auf diese Weise lässt sich das Verhalten einer Anwendung im Nachhinein Schritt für Schritt vor- und zurückspulen, um zu sehen, wie sich Daten und Darstellung infolge einer Aktion jeweils verändert haben.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

In den Anfangstagen von Redux waren hingegen große Mengen an Boilerplate-Code gefürchtet, die komplexe Anbindung an React-Komponenten und die sehr spezielle API zum Arbeiten mit Seiteffekten (zum Laden von Daten von einem Server) in Form von Thunk Actions. Erschwerend kam hinzu, dass es zu der Zeit noch nicht üblich und möglich war, React und Redux vollständig typsicher, beispielsweise mit TypeScript, zu entwickeln. Entsprechend groß war die Gefahr, dass sich Fehler in den Programmcode einschlichen. Ungeachtet der Stolpersteine war und ist Redux aber aus vielen React-Projekten nicht wegzudenken.

Einige der geschilderten Probleme gehören mittlerweile der Vergangenheit an: Die Weiterentwicklung von Redux haben Mark Erikson und Lenz Weber-Tronic übernommen, die 2019 das Redux Toolkit (ursprünglich "Redux Starter Kit") veröffentlichten. Es vereinfacht nicht nur die Konfiguration und Installation von Redux erheblich, auch die APIs sind einfacher und dank umfassendem TypeScript-Support auch weniger fehleranfällig in der Bedienung. Das komfortable Arbeiten mit Daten vom Server unterstützt das Redux Toolkit zudem durch das integrierte RTK Query.

Einführung und Trennung von Klassen

Das Jahr 2015 markierte nicht nur für React einen Einschnitt, sondern für die gesamte JavaScript-Community. Mitte dieses Jahres erschien das lang erwartete "große" neue JavaScript-Release ECMAScript 6, das eine ganze Reihe von Neuerungen mitbrachte. Da es viele berüchtigte Schwächen der Sprache behoben hat, wird es auch als "modernes JavaScript" bezeichnet. Zu den Neuerungen, die mittlerweile im Alltag gängig sind, zählen Block Scoping mit let und const, die Pfeil-Funktionen, die Promise API und auch die Unterstützung von Klassen mit dem class-Schlüsselwort.

Bereits Anfang 2015 wurde die createClass-Funktion zum Erzeugen von Komponenten durch die nativen JavaScript-Klassen in der React API ersetzt – gleichwohl lässt sich die createClass-API bis heute nahezu unverändert verwenden.

Das React-Team selbst stellte den Einsatz von Klassen immer wieder infrage. Sie seien zu komplex und insbesondere das this-Binding sei schwer verständlich und fehleranfällig. Noch im selben Jahr führte das Team daher die "Stateless function components" ein. Die neue API legte die Basis, um React-Komponenten ausschließlich mit JavaScript-Funktionen zu schreiben. Sie knüpft technisch an eine Grundidee von React an, nach der das UI sowie die UI-Komponenten als Funktionen anzusehen sind ("UI as a Function"), in die sich Daten einreichen lassen, und die für dieselben Daten immer dasselbe UI zurückgeben. Da die UI-Funktionen frei von Seiteneffekten sind, verhalten sie sich konzeptionell ähnlich wie mathematische Funktionen, die ebenfalls für dieselben Eingangsdaten immer dasselbe Ergebnis erzeugen – unabhängig vom Kontext oder Zeitpunkt ihres Aufrufs.

Der neue Ansatz blieb zunächst allerdings auf zustandslose Komponenten beschränkt, die allein der Darstellung dienten. Nach langem Warten, vielen Spekulationen und Experimenten erfolgte erst Anfang 2019 mit der Einführung der viel diskutierten React Hooks-API der Umstieg auf eine vollständig funktionsbasierte API. Seither ist es möglich, React-Komponenten nur mit JavaScript-Funktionen zu entwickeln.

Hooks-API: Abschied von den ungeliebten Klassen

Mit der Hooks-API bleibt React seinem eigenen Weg treu, Dinge anders als andere zu machen. Im Blog-Post zur Vorstellung der Hooks-API heißt es zur Begründung, warum man nicht weiter auf Klassen setzen wolle, Klassen würden Menschen und Maschinen verwirren. Diese Aussage ist nicht nur aufgrund ihrer Abwegigkeit bemerkenswert. Die Hooks-API ist zwar einfach in der Bedienung und löst viele Probleme der Klassen-API. Allerdings schafft sie auch neue Probleme, die ebenfalls viele Entwicklerinnen und Entwickler verwirren – davon zeugen zahlreiche Blogposts, Tutorials und YouTube-Filmchen zu Hooks wie useEffect, useCallback oder useMemo. Trotz allem hat sich die Hooks-API als Standard-API mittlerweile durchgesetzt.

Die Einführung der Hooks-API ist aber auch ein bemerkenswertes Beispiel für die steten Bemühungen des React-Teams, größtmögliche Abwärtskompatibilität sicherzustellen. Die Einführung der komplett neuen API erfolgte ohne Breaking Changes in der Minor-Version React 16.9. Im zugehörigen Blogpost warnte das Team explizit davor, bestehende Anwendungen sofort auf die neue API umzustellen. Entwicklerinnen und Entwickler sollten die API in ihren Anwendungen lieber Schritt-für-Schritt einführen, zum Beispiel beim Bau neuer Features. Und tatsächlich gilt auch Reacts Klassen-API bis heute nicht als deprecated (veraltet), sondern funktioniert ohne Einschränkungen weiter.

Das React-Release 16.0 vom September 2017 markiert den Start einer neuen internen React-Architektur mit dem Namen Fiber. Damit kann React das Rendern von Komponenten nun kleinteiliger steuern und auch abbrechen, um beispielsweise bestimmten Aktualisierungen der Oberfläche eine höhere (dringendere) Priorität einzuräumen. Erklärtes Ziel dabei ist es, dass sich die Oberfläche für Benutzerinnen und Benutzer reaktiver anfühlt. Auch diesen Umbau konnte das React-Team abwärtskompatibel umsetzen, ohne Anpassungen am Anwendungscode.

Aufgrund der hohen Abwärtskompatibilität empfiehlt sich React nach wie vor auch für den Einsatz in langlebigen Enterprise-Anwendungen. React wirbt explizit damit, dass alle Änderungen stets Tests an "über einhunderttausend Komponenten" bei Meta intern durchlaufen. Neue Releases erscheinen nur mit einer daran erprobten Migrationsstrategie. Der damit verbundene Aufwand führt mitunter zu längeren Releasezyklen. Daher hat das React-Team jüngst bekannt gegeben, einen sogenannten Canary-Release-Kanal einzuführen. Darüber sollen Releases künftig auch schon vorab zur Verfügung stehen, damit sich neue und experimentelle Features vorab auszuprobieren lassen. Per Feature-Toggle können Entwicklerinnen und Entwickler dabei die Neuerungen in eigenen Anwendungen bei Bedarf ein- und ausschalten.

Neben der Hooks-API ist mittlerweile auch der Einsatz von TypeScript zum Standard in der React-Entwicklung avanciert, obwohl React selbst nach wie vor nicht mit TypeScript entwickelt wird und das React-Team auch die TypeScript-Typ-Definitionen nicht pflegt. Die React-Entwicklung erfolgt weiterhin mit Flow. Dabei handelt es sich – wie bei TypeScript – um einen statischen Typ-Checker für JavaScript-Code. Das 2012 veröffentlichte TypeScript und das 2014 erschienene Flow lieferten sich anfangs ein Kopf-an-Kopf-Rennen um Features, Verbreitung und Beliebtheit bei Entwicklern und Projekt-Teams. Mittlerweile hat TypeScript dieses Rennen klar für sich entschieden und kommt auch in einer Reihe typischer React-Bibliotheken zum Einsatz. Die React-Code-Basis allerdings wird weiterhin mit Flow entwickelt und es gibt offenbar auch keine Bestrebungen, das zu ändern. Für den Einsatz von TypeScript in einem eigenen React-Projekt spielt das allerdings keine Rolle. Denn das React-Team pflegt die TypeScript-Typen zwar nicht, bietet in Zusammenarbeit mit Microsoft aber Hilfe für Entwicklerinnen und Entwickler, die TypeScript mit React verwenden möchten. Unter anderem kann TypeScript bereits seit dem Release 1.6 JSX-Code überprüfen und in JavaScript-Code übersetzen.

Startschwierigkeiten neuer Projekte überwunden

In den zehn Jahren seit Erscheinen von React blieb nicht nur die Frage, welchen Typ-Checker man verwenden sollte, ein immer wieder diskutiertes Thema. Die Anfangszeit von React – und die der Single-Page-Anwendungen – war geprägt vom Kommen und Gehen zahlreicher Bibliotheken und Tools im JavaScript-Umfeld. Der Spruch, es gäbe JavaScript-Bibliotheken, die kürzer haltbar seien als ein Liter frischer Milch, machte die Runde, und die "JavaScript Fatigue" breitete sich aus. Allein das Aufsetzen, Konfigurieren und Pflegen des Build-Tool-Stacks für eine typische React-Anwendung artete schnell zur Vollzeit-Aufgabe aus: Webpack mit seinen unzähligen Loadern und Plug-ins musste zur Babel-Version mit dessen Plug-ins passen, die wiederum zur entsprechenden React-Version passen musste – von TypeScript, ESLint und dem Webpack Development Server ganz zu schweigen.

Viele dieser Probleme löst bislang das Tool create-react-app, das ein funktionsfähiges Projekt-Set-up bereitstellt, sodass sich neue Projekte mittlerweile schnell einrichten lassen. Auch für das mittlerweile sehr populäre Frontend-Build-Tool Vite gibt es ein React Template zum Erzeugen neuer React-Projekte.

Für typische Anforderungen an React-Anwendungen gibt es inzwischen De-facto-Standards. Dazu gehören der React Router für das Routing, SWR oder Tanstack Query für das Arbeiten mit Daten vom Server. Zum Testen von React-Anwendungen hat sich Jest in Kombination mit der react-testing-library weitgehend durchgesetzt. Auch das noch recht neue Browser-Test-Tool Playwright bietet (experimentelle) Unterstützung für das Testen von React-Komponenten.

Angular-2-Moment oder Aufbruch in eine neue Epoche?

React hat sich in den letzten Jahren eher langsam, aber doch stetig weiterentwickelt. Releases und neue Features blieben oftmals überschaubar. Legendär war das Major-Release 17, in dessen Ankündigung prominent die Aussage prangte: "No New Features". Auch vom ursprünglichen Claim einer Bibliothek zur Entwicklung von Benutzeroberflächen weicht das Entwicklungsteam bisher nur geringfügig ab: "Die Bibliothek für Web- und native Benutzeroberflächen“.

Was die Zukunft von React angeht, ist allerdings mehr Spannung zu erwarten. In den vergangenen Jahren kamen immer wieder Diskussionen darüber auf, wie sich React-Anwendungen noch effizienter ausführen und neue Anwendungsfälle erschließen lassen. Eine Idee dabei ist, React-Anwendungen ganz oder teilweise zur Laufzeit auf dem Server zu rendern und ganz oder teilweise als fertigen UI-Code zum Client zu senden. Dazu hatte das React-Team Ende 2020 die React Server Components vorgestellt, die bislang noch nicht in einer stabilen Version vorliegen. Im Gegensatz zu den klassisch Client-seitig gerenderten Single-Page-Anwendungen (SPA) benötigt es für diese Komponenten nämlich einen JavaScript-Server zur Laufzeit, den React aber nicht bereitstellt. Stattdessen empfiehlt die Dokumentation für vollständige React-Anwendungen seit Anfang 2023 ganz offen den Einsatz eines sogenannten Fullstack-Frameworks wie Next.js oder Remix. Auch in Diskussionen und Nachfragen zum Beispiel auf GitHub und Twitter bestätigen die Mitglieder des React-Teams diese Einschätzung.

Innerhalb der React-Community herrschte lange Zeit im Großen und Ganzen eine gute Stimmung, mit dieser Entscheidung könnte sich das ändern. Zumindest zurzeit wirkt die Community in dieser Frage gespalten. Für die einen beginnt eine "neue Ära" für React, die jetzt auch den serverseitigen Einsatz ermöglicht. Sogar von React als "PHP++" ist hier unironisch die Rede. Auf der anderen Seite melden sich diejenigen zu Wort, die aus unterschiedlichen Gründen die vorgestellten serverseitigen Features zu kompliziert finden, diese nicht benötigen oder nicht einsetzen wollen und den Fokus lieber auf die Lösung anderer Probleme gelegt gesehen hätten. In diesem Teil der Community ist gar von einem "Angular-2-Moment" die Rede – eine Anspielung auf die Ankündigung der zweiten Major-Version von Angular im Jahr 2014. Damals änderte Google zahlreiche APIs in Angular, bot aber keine Migrationsstrategie von der vorherigen Version an. Mittlerweile trägt die erste Version auch die Bezeichnung AngularJS, während alle Versionen danach Angular heißen, um den Wandel deutlich zu machen.

Auf zu neuen Ufern

Unabhängig von der Frage, wie gravierend die neue Ausrichtung von React sein mag, die Kommunikation seitens des React-Teams hätte besser sein können. Nicht zu Unrecht fühlen sich Anhängerinnen und Anhänger der klassischen Single-Page-Anwendungen abgehängt. Und zwischen den Zeilen kann man aus den Kapiteln in der Dokumentation zu dem Thema auch herauslesen, dass dieser klassische Ansatz "falsch" sei. Etwas verklausuliert ist die Rede von "ungewöhnlichen Anforderungen", die eine Anwendung nun haben müsse, damit der klassische SPA-Ansatz weiterhin gerechtfertigt sei.

Wie auch immer diese Diskussion ausgehen mag und welche Konsequenzen sich für den Einsatz von React ergeben, lässt sich jetzt schon festhalten: Die nächste Zeit wird spannend. Denn über die Frage des serverseitigen Einsatzes hinaus sind weitere neue Features angekündigt. So soll sich unter anderem das Arbeiten mit Server-Aufrufen und geladenen Daten mit einem neuen Hook einfacher gestalten. Dazu gehört auch das lang angekündigte "Suspense for Data Loading", das in Data-Fetching-Bibliotheken wie Tanstack Query bereits in einer experimentellen Version zur Verfügung steht. Außerdem arbeitet das React-Team bereits seit einiger Zeit an einem eigenen Compiler, der Code erzeugen soll, der das Neurendern von Komponenten überflüssig macht. Genügend Themen und Herausforderungen für die nächsten zehn Jahre von React gibt es also!

Nils Hartmann
ist freiberuflicher Softwareentwickler und -architekt. Er unterstützt, berät und schult Teams bei der Arbeit mit Java, Spring, GraphQL, React und TypeScript.

(map)