Das Beste an moderner Webentwicklung ist, dass es in diesem Themengebiet so unglaublich viele Ressourcen gibt. Das Schlimmste an moderner Webentwicklung ist, dass es so unglaublich viele Ressourcen gibt, so dieser Autor in seinem Artikel auf Medium. Das mag euch vielleicht bekannt vorkommen.

Wer gerade erst angefangen hat, sich mit Entwicklungsthemen zu befassen, ist oft schon mit der bloßen Entscheidung, was er oder sie als nächstes – oder als erstes – lernen sollte, überfordert. Angular, Vue, Firebase, Bootstrap, Node.js, Docker, Python, Rust, Redux, Git, Babel, Webpack, Kotlin … die Liste ließe sich unendlich fortführen. Um zu verstehen, was hinter dem Hype um React steckt, ist es wahrscheinlich sinnvoll, ein paar Basics verstanden zu haben.

Eine Webanwendung besteht aus Frontend und Backend respektive Client-Side und Server-Side. Das Backend besteht aus Server, Applikation und Datenbank. Der Server kommuniziert mit der Datenbank und hostet eure Anwendung. Das Backend schickt Daten an das Frontend. JavaScript konvertiert diese Daten in HTML. Eine Webanwendung besteht grundsätzlich aus beidem, Frontend und Backend. Im Browser manifestiert sich das Frontend in Form einer Benutzeroberfläche, also dem, was ihr seht und womit ihr interagiert.

React ist ein JavaScript-Framework oder eine Library für die Entwicklung von User-Interfaces. Eigentlich ist der Begriff Library ganz passend: In einer Bibliothek gibt es eine Auswahl von Büchern, die von Bibliothekaren kuratiert und für euch sortiert wurden. Wenn ihr ein Buch aus der Bibliothek braucht, könnt ihr es einfach über das Bibliothekssystem finden und ausleihen. In einer JavaScript-Library gibt es zwar keine Bücher, dafür aber fertigen Code, auf den ihr zugreifen könnt.

Andere Frameworks mit demselben Zweck sind zum Beispiel Vue oder Angular. Mit anderen Worten: React ist eine Library für die Frontend-Entwicklung. Ein Frontend zu bauen, geht natürlich auch ohne Framework mit „reinem“ JavaScript, das auch Vanilla JavaScript genannt wird. Entwickelt wurde React von Facebook: Die Facebook-App und die Webversion basieren beide auf der Library. React eignet sich besonders gut für Single-Page-Applikationen und für interaktive Apps.

In einer Web-App gibt es verschiedene Ansichten oder Views. Klickt ihr auf einem UI irgendwo drauf, ändert sich die View. Viele Internetnutzer assoziieren eine Änderung der View vielleicht mit einem Seitenwechsel. Das ist nicht falsch: Frühere Webanwendungen bestanden typischerweise aus mehreren verschiedenen Seiten. Wenn eine neue View angezeigt werden sollte, musste dafür eine neue Seite geladen werden.

Eine modernere Herangehensweise sind Single-Page-Applications oder SPA. Eine Single-Page-Application besteht aus verschiedenen Views – bei nur einer einzelnen Seite. Diese Single-Page enthält alle vorhandenen Views – die aktive kann dynamisch getoggelt werden. In einer Multipage-App wären alle Views, die eure Anwendung bietet, auf einer separaten Seite. Klickt ein User zum Beispiel auf einen Sign-in-Link in der Navigationsleiste, müsste dafür eine neue Seite, die die Sign-in-Ansicht enthält, geladen werden. Bei einer Single-Page-App ändert sich beim Klick auf Sign-in je nach State einfach die aktive View, das Laden einer separaten Seite ist nicht nötig. Aber was ist eigentlich ein State?

Reacts Stärke liegt darin, dass es den State in einer Anwendung verwaltet. Der State kann vielleicht am besten beschrieben werden als der gegenwärtige Istzustand der Applikation. Ruft ihr zum Beispiel eine Website im Browser auf, startet die Seite mit einem initialen State. Vielleicht klickt ihr dann auf der Website und klappt ein Menü auf. Sobald das Menü aufgeklappt ist, befindet sich die Website in einem neuen State. Vielleicht klickt ihr dann noch auf einen Like-Button. Das versetzt die Anwendung erneut in einen anderen State – die Anzahl der Likes wird aktualisiert.

Auf einer Website könnt ihr oft noch eine ganze Reihe weiterer Sachen machen. Jede davon bedeutet einen eigenen State. Das Verhalten der einzelnen Komponenten zum Beispiel in einem mit Vanilla JavaScript gebauten Double der React-App so zu orchestrieren, dass alle möglichen Aktionen in ihrem jeweiligen State korrekt abgebildet werden, ist kompliziert – ihr erinnert euch: Für jede mögliche View bräuchte es eine eigene Seite, auf der – figurativ gesprochen – jeder Komponente einzeln gesagt wird, wie sie sich zu verhalten hat.

Eines der Hauptmerkmale Reacts ist, dass in React geschriebene Programme komponentenbasiert sind. Komponenten sind die Blöcke, aus denen eine View besteht. Also zum Beispiel ein Button oder ein Drop-down-Menü. Mit React könnt ihr quasi innerhalb der Anwendung vordefinierte Codebits programmieren, die ihr anschließend zu einer View zusammensetzt. Eine solche Komponente könnt ihr innerhalb der Anwendung beliebig in andere Views einbinden.

React ist deklarativ – die Programmlogik zielt darauf ab, wie etwas aussehen soll. React speichert eine zentrale Wahrheit, die an alle Komponenten weitergegeben wird. Komponenten in React sind so aufgebaut, dass sie den State wiedergeben. Wenn ihr in einer mit React gebauten Single-Page-App den Like-Button klickt, weiß der Zähler, welche Zahl er anzeigen muss – und solange jede Komponente basierend auf demselben State gerendert wird, weiß React auch, wie der Rest der Seite auszusehen hat. Imperative Logiken zielen im Gegensatz dazu darauf ab, der Anwendung zu sagen, was  sie tun soll. Um das einmal in natürlicher Sprache zu illustrieren: Deklarative Logiken sind, als würdet ihr zu eurem Mitbewohner sagen: „Wir brauchen Klopapier“. Im Gegensatz dazu sagt ihr ihm in einer imperativen Syntax die Schritte, die ausgeführt werden müssen: „Geh aus der Tür, nimm Geld mit, geh zum Supermarkt und kauf Klopapier.“

Beides funktioniert, letzteres ist aber länger, komplizierter und damit fehleranfälliger. Deklarativer Code ist meistens leichter zu debuggen, weil einfacher ersichtlich ist, was der Code will, während ihr bei vielen Zeilen imperativen Codes oft länger braucht, um zu verstehen, was damit erreicht werden soll.

Diese Frage lässt sich natürlich nie pauschal beantworten. Wer in Richtung Webentwicklung gehen will und von den oben genannten Punkten nicht bereits überzeugt ist: ja, auf jeden Fall. Das Framework wird seit Jahren immer populärer. Mit neuen Releases kommen auch regelmäßig neue Features dazu, die den Nutzern das Leben vereinfachen sollen. Zuletzt wurde beispielsweise ein neues, noch nicht veröffentlichtes Konzept namens React Server Components vorgestellt, das es ermöglichen soll, Komponenten künftig von der Client- auf die Serverseite zu verlagern. Die Dokumentation ist wirklich gut, sehr ausführlich und beinhaltet eine Menge Tutorials, an denen ihr euch austoben könnt. Es gibt eine Menge toller Features, Extensions und Tools und eine lebhafte Community um das Framework. Außerdem ein großer Pluspunkt für die Library: Beherrscht ihr React, beherrscht ihr auch React Native – React für die Entwicklung nativer Apps. Fun Fact: Die Entwickler bei t3n nutzen die Library übrigens auch.

Passend dazu:  React-Hooks – lohnt die Umstellung auf das Programmierkonzept?