React 19.3, Bun 1.4 і Node.js: що принесли релізи серпня та вересня

Огляд охоплює 4 серпня — 4 жовтня 2026 року. Таблиця містить вибрані релізи, які пояснюють зміни нижче; повні журнали доступні в офіційних джерелах. Дати взято з release notes. Для Node.js 24.21.0 це 8 вересня, хоча картка в блозі датована 9 вересня.

9 вересня React випустив 19.3. <ViewTransition> перейшов зі статусу експериментального API у стабільний: компонент координує анімації появи, зникнення та переміщення елементів через браузерний View Transition API. Оновлення має бути позначене як Transition, наприклад через startTransition. Це конкретний інструмент для перемикання екранів або розкриття Suspense-контенту. [1]

Fragment Refs дозволяють передати ref у <Fragment> і працювати з групою DOM-вузлів: керувати фокусом, подіями чи спостереженням за видимістю. Так можна прибрати обгортку, яку раніше додавали тільки заради ref. use(browser()) із react-dom призупиняє рендер компонента на сервері; в початковому HTML показується найближчий Suspense fallback. [1]

Для нашого підходу static-first це означає вибір окремих інтерактивних ділянок. Основний текст, навігація та зміст сторінки мають залишатися в початковому HTML. Віджет, який читає локальні дані браузера, можна оцінювати окремо; browser() переносить його зміст на клієнт. Після оновлення варто перевірити сторінку з вимкненим JavaScript, гідратацію та навігацію клавіатурою.

Стабільність React API також потребує перевірки інтеграції з фреймворком. Якщо сайт уже має власний компонент переходів, новий механізм варто спершу ввімкнути на одному сценарії: подвійна анімація, поведінка Back і налаштування reduced motion краще видимі на маленькому прикладі.

Bun 1.4 вийшов 20 серпня і став першим релізом Bun на Rust. Анонс також збирає можливості, додані від часу 1.3.0; позначка біля кожного API вказує, в якій версії він з’явився. Тому, наприклад, наявність Bun.Image у великому огляді сама по собі не означає, що API дебютував саме в 1.4. [2]

Команда Bun повідомляє про 1 517 додаткових тестів із набору Node.js, які проходять у новій версії. Це корисний показник роботи над сумісністю. Для нашого API окремою умовою переходу залишаються залежності, native-модулі та поведінка запитів; загальна кількість тестів цього не встановлює. Переписування runtime на Rust теж саме по собі не дає виміряного прискорення застосунку. [2]

У 1.4.1 з’явилися HTTP/2 у Bun.serve та запис Response через Bun.write потоком на диск. Для сервісу, який завантажує великі файли, друга зміна дає конкретний привід перевірити пікову пам’ять під паралельними завантаженнями. В HTTP/2 є обмеження: release notes вказують, що WebSockets і response trailers через нього ще не підтримуються. [3]

Уже 5 вересня вийшов 1.4.2. Патч виправив конфлікт назв змінних у bun build, що ламав Elysia, і регресію AsyncLocalStorage з версії 1.4.1. Таймер або promise, створений усередині exit() чи вкладеного run(), міг утримувати зовнішній store у пам’яті. getStore() повертав правильне значення, тому звичайна перевірка request ID могла пройти, а пам’ять усе одно залишалася зайнятою. [4]

Саме цей випадок визначає нашу рекомендацію: для пілоту гілки 1.4 варто взяти 1.4.2 та включити сценарій довгоживучого процесу. Перевірка одного успішного запиту тут недостатня. Спостерігайте за пам’яттю після серії запитів із великим контекстом, вкладеним run() і фоновими таймерами; це запропонована перевірка, власних результатів такого тесту ми в цій статті не наводимо.

У Node.js за цей період оновлювалися кілька гілок. 26.9.0 додав Web Workers, інтеграцію віртуальної файлової системи із CJS/ESM loaders та node:bench. Для bench у changelog зазначений прапорець --experimental-bench; статус конкретного API слід звіряти з документацією своєї версії. 26.10.0 розширив роботу з криптографією, файлами та гістограмами. Обидва релізи мають статус Current. [6][7]

Для production API ми б починали з підтримуваної LTS-гілки. Node.js 24.21.0 оновив OpenSSL до 3.5.8 та Undici до 7.29.1, а 22.23.3 приніс оновлення сертифікатів та інструментів. Офіційна політика Node.js рекомендує Active LTS або Maintenance LTS для production. Нові можливості 26.x можна оцінити на окремому пілоті, якщо вони потрібні конкретній задачі. [5][8][9]

Для статичного сайту runtime збірки й runtime хостингу потрібно розглядати окремо. Якщо результатом є HTML, CSS і JavaScript-файли, відвідувач не запускає Node.js сервера збірки. Оновлення Node.js у CI впливає на встановлення пакетів та експорт; перенесення окремого API на Bun змінює серверну поведінку. Ці роботи зручніше робити різними змінами, щоб причина регресії залишалася видимою.

Це шаблон PAS7 для порівняння, а не звіт про проведений бенчмарк. Оберіть сторінку або API-маршрут, який використовує змінений механізм. Запишіть точні версії, ОС, commit і параметри навантаження; змінюйте одну залежність або runtime за раз. Числові результати внесіть після власного запуску.

Для порівняння продуктивності додайте однакове прогрівання та повторні запуски. Оцінюйте p95 і помилки разом із пам’яттю, а допустиму регресію визначте заздалегідь. Час bun install, час статичної збірки та затримка HTTP-запиту описують різні задачі; для кожної потрібен свій запис результату.

Для команди з React-фронтендом і Node.js API наступний крок може бути невеликим: перевірити один перехід на React 19.3, окремо оновити LTS у CI та зіставити Bun 1.4.2 з наявним runtime на одному маршруті. Рішення про ширший перехід має спиратися на результат цього порівняння. Наступний сигнал для спостереження — підтримка потрібних React API вашим фреймворком і патчі runtime, які зачіпають саме ваші залежності.