React 19.3 im Vergleich zu React 18: Was sich für Produktteams wirklich geändert hat

React 19.3 erschien am 9. September 2026. Die meisten Release-Beiträge lesen sich wie eine Feature-Liste; ich lese sie als Liste von Code, den ich löschen kann. Verglichen mit React 18 – der Version, auf der noch viele Produktivsysteme laufen – geht es in der 19er-Reihe weniger um neue Syntax als darum, teaminterne Workarounds abzuschaffen: Zustandsautomaten für Formulare, forwardRef-Wrapper, memo überall und typeof-window-Prüfungen.

React 19.0 legte das Fundament. Actions und useActionState ersetzten bei jedem Formular die selbst gebaute Kombination aus isPending, error und data. useOptimistic machte optimistische UI zu einem Hook statt zu einem Reducer. use() liest während des Renderns ein Promise oder einen Context – auch bedingt. ref wurde zu einer normalen Prop, forwardRef ist damit Altbestand; <Context> funktioniert selbst als Provider; <title> und <meta> werden aus jeder Komponente in den head gehoben. Der Umstieg hatte aber seinen Preis: String-Refs, Legacy Context, ReactDOM.render und propTypes bei Funktionskomponenten wurden entfernt. Eine React-18-App mit alten Abhängigkeiten braucht daher ein echtes Upgrade, nicht bloß eine höhere Versionsnummer.

React 19.2 und React Compiler 1.0 änderten das Arbeitsgefühl. <Activity mode="hidden"> hält einen Tab oder die nächste Seite samt Zustand gemountet, während die Effekte pausieren – etwas, das wir früher mit display: none und viel Hoffnung nachgebaut haben. useEffectEvent beendet den Streit mit der exhaustive-deps-Regel: Der Effekt reagiert auf roomId, der Callback liest einfach das neueste Theme. Partielles Prerendering (prerender, dann resume) ermöglicht es, ein statisches Grundgerüst vom CDN auszuliefern, während der dynamische Teil gestreamt wird. Der Compiler machte zudem die meisten manuellen useMemo-, useCallback- und React.memo-Aufrufe überflüssig. Ich behalte sie dort, wo eine Bibliothek referenzielle Identität braucht, aber sie sind kein Reflex mehr.

Bei React 19.3 geht es um Animationen und die Grenzen des DOM. <ViewTransition> ist jetzt stabil: Ein Element wird umschlossen, die Aktualisierung mit startTransition markiert, und der Browser animiert Einblenden, Ausblenden und gemeinsame Elemente. Mit addTransitionType können „next“ und „previous“ bei derselben Zustandsänderung in unterschiedliche Richtungen gleiten. Fragment-Refs bieten focus(), observeUsing() für IntersectionObserver sowie Messungen einer Geschwistergruppe ohne zusätzliches Wrapper-div. use(browser()) aus react-dom ersetzt die Prüfung typeof window !== "undefined": Die Komponente suspendiert auf dem Server, zeigt den Suspense-Fallback und rendert nach der Hydrierung auf dem Client. Server Components können <Context value> direkt rendern, ohne eine Provider-Datei mit „use client“; außerdem reicht react-dom Trusted-Types-Objekte unverändert weiter, statt sie in Strings umzuwandeln. So funktioniert React auch mit einer strikten CSP-Regel require-trusted-types-for.

Im direkten Vergleich zeigt sich der Unterschied an den Imports. Unter React 18 bedeutete ein Formular mit Ladezustand, optimistischem Update und animierter Liste drei Bibliotheken plus eigenen Hook. In 19.3 reichen useActionState, useOptimistic und <ViewTransition> aus React selbst. „Nur auf dem Client rendern“ hieß in 18: ein mounted-Flag und ein Layoutsprung; jetzt genügen eine Zeile und eine Suspense-Grenze. Performance bedeutete in 18, memo diszipliniert einzusetzen; heute liefern der Compiler und React Performance Tracks in Chrome DevTools Hinweise darauf, was tatsächlich einen Frame blockiert.

Was ich nicht tun würde: ein Produkt, das Geld verarbeitet, in einem Pull Request von 18 auf 19.3 heben. Mein absichtlich unspektakulärer Weg: erst auf 18.3 wechseln, um Deprecation-Warnungen zu sehen; dann React 19 mit den offiziellen Codemods; danach den Compiler hinter einem Feature-Flag auf einer Route testen; neue APIs erst dort einsetzen, wo sie Code entfernen. 19.3 selbst ist additiv – der Release-Beitrag nennt keine Breaking Changes. Die Sicherheitsmeldungen zu Server Components vom Dezember 2025 erinnern dennoch daran, dass Patch-Versionen ebenso wichtig sind wie Major-Releases. Läuft deine App noch auf 18, schick mir package.json und die drei wichtigsten Screens. Ich antworte mit der Upgrade-Reihenfolge und dem Code, den du anschließend löschen kannst.