<b>RSC — не «замена React», а другой контракт между сервером и клиентом</b>

<b>RSC — не «замена React», а другой контракт между сервером и клиентом</b>

Если упростить, React Server Components нужны не для «ускорить всё», а чтобы <i>не тащить лишний JS на клиент</i>. Сервер рендерит то, что не требует интерактива, а в браузер уезжают только клиентские островки.

Главная ошибка — считать, что RSC автоматически решает perf. Нет: они убирают бандл, но не отменяют дорогие запросы, тяжёлые вычисления и плохую композицию. Если страницу всё равно блокирует один медленный API, магии не будет.

На практике полезно смотреть на RSC так:
— статичный/слабодинамический слой держим на сервере;
— интерактивные части выносим в client components точечно;
— состояние и эффекты не размазываем по всему дереву;
— границу <code>'use client'</code> ставим как можно ниже.

Есть ещё одна ловушка: серверный компонент нельзя мыслить как обычный UI-компонент. Он живёт в другом мире — без браузерных API, без локального state и без привычных хаков. Зато там удобно собирать данные, формировать дерево и отдавать уже готовую структуру.

Если проект растёт, RSC помогают дисциплинировать архитектуру: меньше случайной интерактивности, меньше JS, понятнее, где именно возникает стоимость. Хороший вопрос к себе перед внедрением простой: <i>какая часть этой страницы реально должна быть в браузере?</i>