RSC вне Next.js: фреймворк — это бандлер

RSC — инфраструктура React, а не фича фреймворка

Протокол RSC и его эталонные реализации поставляются из самого репозитория React в виде биндингов под конкретные бандлеры: react-server-dom-webpack, с собратьями для других сборщиков (у Turbopack и Parcel свои пакеты; интеграция с Vite зрела отдельно как плагин). Серверная половина экспортирует функции вроде renderToPipeableStream — но из react-server-dom-webpack/server, и производит Flight-поток, а не HTML; клиентская половина даёт createFromFetch / createFromReadableStream, которые потребляют поток и вручают React дерево для рендера. Нигде здесь не упомянут Next.js. Что Next.js (и любой другой RSC-фреймворк) добавляет — это машинерия вокруг протокола, и недооценка этой машинерии — двухспринтовый урок из Hook.

Участвует и вторая сборка React: пакеты подписываются на условие экспорта react-server, и под ним react резолвится в сборку, где клиентские хуки попросту не существуют — useState в серверном компоненте падает на резолве модуля, а не из вежливости в рантайме. Ваш серверный и клиентский бандлы резолвят разный код для одного и того же импорта. Уже одна эта деталь дисквалифицирует подход «просто запустим один бандл с обеих сторон».

Четыре части минимальной RSC-инсталляции

Уберите весь фреймворк — несводимый чек-лист состоит из четырёх пунктов:

1. Flight-сервер. Нечто, что берёт запрос, рендерит дерево серверных компонентов под условием react-server и стримит пейлоад. Десятки строк поверх react-server-dom-webpack/server.
2. Плагин бандлера, ведущий два графа модулей. Он должен найти каждую директиву 'use client', разрезать граф в этом месте, собрать клиентскую сторону в чанки и — часть, о которой все забывают — выдать клиентский манифест: таблицу, маппирующую ссылки на модули из пейлоада ("./RangePicker.js") в чанки и имена экспортов, которые браузер должен загрузить. Ошибитесь в манифесте — и гидрация умрёт с «Could not find the module in the React Client Manifest».
3. Клиентский рантайм. Небольшой бутстрап, который забирает поток, прогоняет его через createFromFetch и рендерит полученное дерево — обычно внутри startTransition, чтобы подмена пейлоада не сносила незавершённый ввод.
4. Роутер, перезапрашивающий пейлоады. Навигация должна перехватывать клики по ссылкам, забирать Flight-пейлоад нового маршрута вместо HTML и реконсилировать его внутрь. Без этого у вас RSC-рендер первой загрузки и полные перезагрузки страниц навсегда — серверные компоненты «перерендериваются при навигации», только если что-то действительно так навигирует.

Пункты 2 и 4 — там, где живёт инженерия. Работа в бандлере инвазивна (два графа, перекрёстные ссылки между ними, синхронные манифесты dev- и prod-сборок, HMR (Hot Module Replacement — горячая замена модулей в dev-сервере), понимающий разрез), поэтому поддержка RSC приходит по-бандлерно и по-фреймворочно, а не одной установкой npm-пакета.

Вместе эти четыре пункта объясняют провал из Hook с хирургической точностью: у команды был пункт 1 (работающий Flight-поток), но не было пунктов 2, 3 и 4 — тех частей, что не являются протоколом, но делают его пригодным к использованию. Без манифеста ссылки из пейлоада никуда не резолвятся; без роутера клиентские компоненты не получают обновлений пейлоада; без условия react-server хуки просачиваются в неправильный бандл.

Кто реализует это сегодня — честная карта

На начало 2026 года пейзаж, если судить по полноте, а не по маркетингу: Next.js App Router — самая полная продакшен-реализация и полигон с 2023 года: RSC, серверные функции, стриминг и кэширование сверху (кэширование — самая критикуемая часть, и это дизайн Next, а не требование RSC). Waku — минимальный эталон: небольшой фреймворк на Vite, построенный вокруг RSC by design; полезен и для лёгкого продакшена, и для чтения — самый чистый способ увидеть четыре части почти без всего остального. React Router (v7, наследующий линию Remix) ведёт работу по поддержке RSC как направлению-преемнику своей экосистемы. Parcel поставляет поддержку RSC со своими биндингами react-server-dom, а усилия вокруг Vite RSC-плагина зреют в сторону того, чтобы RSC стал возможностью бандлера, а не эксклюзивом фреймворка. Честное резюме: одна обкатанная боем реализация, несколько убедительных сходящихся и общий для всех слой протокола. Чего ждать не стоит: что RSC встанет в существующий CRA или голый webpack-SPA — CRA устарел и заморожен, его конфиг старше директивы; плагин бандлера вы писали бы сами, а это ровно та работа, которой вы пытались избежать.

Что переносится — и что покупает сложность

Всё из первого и второго уроков переносимо между фреймворками, потому что лежит на уровне протокола: серверные компоненты как слой данных с нулевым бандлом, 'use client' как разрез графа модулей, правила сериализации, DTO-дисциплина на границе, паттерн children, серверные функции как публичные эндпоинты. Выучите один раз — в Next, Waku, React Router и в чём угодно поверх Flight это одно и то же; различаются лишь файловые конвенции и семантика кэширования.

Абзац компромисса, которого заслуживает ваше архитектурное ревью: RSC берёт настоящий налог сложности — две среды исполнения, граница сериализации, способная утечь или упасть, инфраструктура, сцепленная с фреймворком, более трудная отладка (стек-трейс, начинающийся на сервере и кончающийся в hydration mismatch) и переобучение команды. Классический SPA + REST API сохраняет одну ментальную модель и позволяет маленькой команде просто выпускать; если ваш продукт — дашборд за логином, где бандл закэширован после первого визита, а SEO неважно, RSC может купить вам мало. Он окупается там, где его структура совпадает с продуктом: контентные и данные-тяжёлые страницы, чувствительная к бандлу аудитория, большие команды, выигрывающие от навязанного раздела данные/UI, и приложения, уже платящие за SSR-слой. Принять половину — дисциплину без инфраструктуры — бесплатно, а дисциплина и есть большая часть senior-ценности этого юнита.