React 19.3, Bun 1.4 und Node.js: Was die Releases im August und September bringen

Dieser Überblick umfasst den Zeitraum vom 4. August bis zum 4. Oktober 2026. Die Tabelle enthält ausgewählte Releases, die die nachfolgenden Änderungen erklären; vollständige Änderungsprotokolle stehen in den offiziellen Quellen. Die Daten stammen aus den Release Notes. Für Node.js 24.21.0 ist das der 8. September, obwohl die Blog-Karte den 9. September nennt.

React hat am 9. September die Version 19.3 veröffentlicht. <ViewTransition> wurde von einer experimentellen zu einer stabilen API: Die Komponente koordiniert Animationen beim Erscheinen, Verschwinden und Verschieben von Elementen über die View Transition API des Browsers. Das Update muss als Transition markiert sein, etwa durch startTransition. Damit gibt es ein konkretes Werkzeug für Bildschirmwechsel oder das Einblenden von Suspense-Inhalten. [1]

Fragment Refs ermöglichen es, eine ref an <Fragment> zu übergeben und mit einer Gruppe von DOM-Knoten zu arbeiten: Fokus, Ereignisse oder Sichtbarkeitsbeobachtung lassen sich so steuern. Dadurch kann ein Wrapper entfallen, der zuvor nur für eine ref eingefügt wurde. use(browser()) aus react-dom unterbricht das Rendern einer Komponente auf dem Server; im initialen HTML erscheint der nächstgelegene Suspense-Fallback. [1]

Für unseren Static-first-Ansatz bedeutet das, einzelne interaktive Bereiche gezielt auszuwählen. Haupttext, Navigation und Seiteninhalt sollten im initialen HTML bleiben. Ein Widget, das lokale Browserdaten liest, lässt sich separat bewerten; browser() verlagert seinen Inhalt auf den Client. Nach dem Upgrade sollten die Seite mit deaktiviertem JavaScript, die Hydrierung und die Tastaturnavigation geprüft werden.

Auch bei einer stabilen React-API muss die Integration mit dem Framework geprüft werden. Hat die Website bereits eine eigene Komponente für Übergänge, sollte der neue Mechanismus zunächst in einem einzigen Szenario aktiviert werden: Überlagerte Animationen, die Zurück-Navigation und Einstellungen für reduzierte Bewegung lassen sich an einem kleinen Beispiel besser beurteilen.

Bun 1.4 erschien am 20. August als erstes Release von Bun auf Rust-Basis. Die Ankündigung bündelt auch Funktionen, die seit 1.3.0 hinzugekommen sind; die Kennzeichnung neben jeder API zeigt, in welcher Version sie eingeführt wurde. Dass etwa Bun.Image in diesem größeren Überblick vorkommt, bedeutet daher allein noch nicht, dass die API erst in 1.4 erschienen ist. [2]

Das Bun-Team berichtet von 1.517 zusätzlichen Tests aus der Node.js-Testsuite, die in der neuen Version bestehen. Das ist ein nützlicher Indikator für die Arbeit an der Kompatibilität. Für unsere API bleiben Abhängigkeiten, native Module und das Verhalten von Anfragen eigenständige Voraussetzungen für eine Migration; die Gesamtzahl der Tests belegt diese nicht. Auch das Umschreiben der Runtime in Rust weist für sich genommen keine gemessene Beschleunigung einer Anwendung nach. [2]

Version 1.4.1 ergänzte HTTP/2 in Bun.serve und das gestreamte Schreiben einer Response auf die Festplatte über Bun.write. Für einen Dienst, der große Dateien herunterlädt, liefert die zweite Änderung einen konkreten Anlass, den maximalen Speicherverbrauch bei parallelen Downloads zu prüfen. HTTP/2 hat Einschränkungen: Laut Release Notes werden WebSockets und Response-Trailer darüber noch nicht unterstützt. [3]

Bereits am 5. September folgte 1.4.2. Der Patch behob eine Kollision von Variablennamen in bun build, die Elysia beeinträchtigte, sowie eine mit 1.4.1 eingeführte AsyncLocalStorage-Regression. Ein Timer oder Promise, der innerhalb von exit() oder einem verschachtelten run() erzeugt wurde, konnte den äußeren Store im Speicher halten. getStore() lieferte den richtigen Wert, sodass eine gewöhnliche Prüfung der Request-ID bestehen konnte, während der Speicher weiterhin belegt blieb. [4]

Dieser Fall begründet unsere Empfehlung: Für einen Pilotversuch mit der 1.4-Linie sollte 1.4.2 verwendet und ein Szenario mit einem langlebigen Prozess einbezogen werden. Eine einzelne erfolgreiche Anfrage reicht hier nicht aus. Beobachten Sie den Speicher nach einer Reihe von Anfragen mit großem Kontext, verschachteltem run() und Hintergrund-Timern. Das ist eine vorgeschlagene Prüfung; eigene Ergebnisse eines solchen Tests führen wir in diesem Artikel nicht an.

In diesem Zeitraum wurden mehrere Node.js-Linien aktualisiert. Version 26.9.0 ergänzte Web Workers, die Integration eines virtuellen Dateisystems mit CJS/ESM-Loadern und node:bench. Für bench nennt das Änderungsprotokoll den Schalter --experimental-bench; der Status einer einzelnen API sollte in der Dokumentation der verwendeten Version nachgeschlagen werden. Version 26.10.0 erweiterte die Funktionen für Kryptografie, Dateien und Histogramme. Beide Releases haben den Status Current. [6][7]

Für eine API im Produktivbetrieb würden wir mit einer unterstützten LTS-Linie beginnen. Node.js 24.21.0 aktualisierte OpenSSL auf 3.5.8 und Undici auf 7.29.1, während 22.23.3 Aktualisierungen für Zertifikate und Werkzeuge brachte. Die offizielle Node.js-Richtlinie empfiehlt Active LTS oder Maintenance LTS für den Produktivbetrieb. Neue Funktionen von 26.x lassen sich in einem separaten Pilotversuch bewerten, wenn sie für eine konkrete Aufgabe benötigt werden. [5][8][9]

Bei einer statischen Website müssen die Runtime für die Erstellung und die Runtime des Hostings getrennt betrachtet werden. Besteht das Ergebnis aus HTML-, CSS- und JavaScript-Dateien, führt der Besucher den Node.js-Build-Server nicht aus. Ein Node.js-Update in CI beeinflusst Paketinstallation und Export; die Umstellung einer separaten API auf Bun verändert das Serververhalten. Diese Arbeiten lassen sich besser in getrennten Änderungen durchführen, damit die Ursache einer Regression erkennbar bleibt.

Dies ist eine PAS7-Vorlage für den Vergleich und kein Bericht über einen durchgeführten Benchmark. Wählen Sie eine Seite oder API-Route, die den geänderten Mechanismus verwendet. Halten Sie genaue Versionen, Betriebssystem, Commit und Lastparameter fest; ändern Sie jeweils nur eine Abhängigkeit oder Runtime. Tragen Sie numerische Ergebnisse nach Ihrem eigenen Testlauf ein.

Für Leistungsvergleiche sollten dieselbe Aufwärmphase und wiederholte Testläufe verwendet werden. Bewerten Sie p95 und Fehler gemeinsam mit dem Speicherverbrauch und legen Sie die akzeptable Regression im Voraus fest. Die Dauer von bun install, die Zeit für einen statischen Build und die Latenz einer HTTP-Anfrage beschreiben unterschiedliche Aufgaben; jede benötigt einen eigenen Ergebniseintrag.

Für ein Team mit React-Frontend und Node.js-API kann der nächste Schritt klein ausfallen: einen Übergang mit React 19.3 prüfen, LTS in CI separat aktualisieren und Bun 1.4.2 auf einer Route mit der bisherigen Runtime vergleichen. Die Entscheidung über eine breitere Migration sollte sich auf diesen Vergleich stützen. Als Nächstes lohnt es sich, die Unterstützung der benötigten React-APIs durch das Framework und Runtime-Patches für die eigenen Abhängigkeiten zu verfolgen.