Next.js / React

React ist eine Bibliothek für Benutzeroberflächen, kein vollständiges Framework. Es beantwortet, wie eine Oberfläche aus Bausteinen entsteht und sich bei Zustandsänderungen aktualisiert — nicht, wie Routen, Datenabruf, Server-Rendering oder Auslieferung funktionieren. Genau diese Lücke füllen Meta-Frameworks, allen voran Next.js.

Daneben stehen Alternativen mit anderen Schwerpunkten. Vue und Svelte verfolgen vergleichbare Ziele mit anderer Syntax und teilweise anderem Aktualisierungsmodell. Astro ist auf inhaltslastige Seiten ausgelegt und liefert standardmäßig sehr wenig JavaScript aus. Für eine weitgehend statische Website ist das oft die passendere Wahl, denn die Stärke von React entfaltet sich bei zustandsreichen, häufig aktualisierten Oberflächen.

Wichtig für die Einordnung ist auch die Rolle von TypeScript. Es ist formal optional, in der Praxis aber der Standard in professionellen Projekten, weil Komponenten mit klar typisierten Eigenschaften eine ganze Fehlerklasse ausschließen und die Werkzeugunterstützung deutlich besser wird.

Zwischen einer Beispielanwendung und einem produktiven Projekt liegen einige Themen, die weder React noch Next.js vorschreiben. Erstens der Umgang mit Zustand: Vieles gehört schlicht in die Komponente, in die URL oder auf den Server. Erst wenn Zustand wirklich weiträumig geteilt wird, lohnen zusätzliche Werkzeuge — der häufigste Fehler ist, sie zu früh einzuführen.

Zweitens der Datenabruf. Sobald Daten im Browser geladen werden, kommen Ladezustände, Fehlerbehandlung, Zwischenspeicherung, erneutes Laden und gleichzeitige Anfragen ins Spiel. Dafür gibt es etablierte Bibliotheken; eigene Lösungen unterschätzen den Aufwand fast immer.

Drittens die Alltagsdisziplinen: Formulare mit Validierung auf beiden Seiten, ein durchgehaltener Ansatz für Styling, Tests für die wichtigsten Abläufe, ein Blick auf die ausgelieferte Paketgröße und eine bewusste Entscheidung, wo die Anwendung läuft — auf einer Plattform mit Serverfunktionen, im eigenen Container oder als komplett vorgerendertes Ergebnis.

Der wirksamste Ratschlag lautet: JavaScript vor React. Wer Funktionen höherer Ordnung, Destrukturierung, Module, Promises und die Arbeit mit Arrays sicher beherrscht, lernt React in einem Bruchteil der Zeit — und erkennt später, welche Probleme aus der Sprache und welche aus der Bibliothek stammen.

Drei Stolpersteine tauchen bei fast allen Einsteigern auf. Der erste ist der übermäßige Einsatz von Effekten: Vieles, was scheinbar einen Effekt braucht, lässt sich direkt beim Rendern ableiten oder im Ereignishandler erledigen. Der zweite ist unnötig kopierter Zustand — dieselbe Information an zwei Stellen zu halten, führt zuverlässig zu Abweichungen. Der dritte ist die unklare Grenze zwischen Server- und Clientlogik im App Router; hier hilft die Frage, ob ein Baustein wirklich Interaktivität oder Browser-Funktionen braucht.

Zur Orientierung: Die Wahl zwischen älterem und neuerem Routing-Ansatz stellt sich bei neuen Projekten kaum noch — der App Router ist die aktuelle Richtung. Für bestehende Projekte ist ein schrittweiser Umstieg möglich; ein vollständiger Umbau ist selten die dringendste Aufgabe.

Ein großer Teil der Frustration entsteht nicht an der Bibliothek selbst, sondern am Drumherum. Praktisch jedes Projekt braucht eine aktuelle Laufzeitumgebung, einen Paketmanager, eine automatische Formatierung und eine Regelprüfung, die häufige Fehler bereits beim Schreiben meldet. Dazu kommen Werkzeuge zum Untersuchen der Komponentenstruktur im Browser und eine Testeinrichtung, die Oberflächen so prüft, wie Nutzer sie bedienen — über sichtbaren Text und Rollen statt über interne Details.

Beim Aktualisieren hilft eine einfache Haltung: regelmäßig in kleinen Schritten statt selten in großen Sprüngen. Wer zwei Hauptversionen überspringt, muss mehrere Umstellungen gleichzeitig verstehen. Größere Versionswechsel bringen in der Regel Migrationsanleitungen und teilweise automatische Umschreibhilfen mit; nützlich ist außerdem, Warnungen in der Entwicklungskonsole ernst zu nehmen, weil sie oft schon auf die nächste Änderung hinweisen.

Und nicht jede Neuerung muss übernommen werden. Ein neues Muster lohnt sich, wenn es ein Problem löst, das im Projekt tatsächlich auftritt — nicht, weil es gerade häufig besprochen wird. Bestehender, funktionierender Code ist selten das dringendste Problem.