Зачем фреймворк поверх React

React рисует в узел, который на странице уже есть. Значит, страница откуда-то берётся — и в приложении на одном React она выглядит одинаково у всех: <div id="root"></div>, тег скрипта с бандлом и больше ничего. Всё остальное, что увидит посетитель, — результат выполнения этого скрипта.

Насколько «ничего» — видно прямо в песочнице: у неё в разметке ровно тот же пустой #root. Прежде чем жать Run, решите, что напечатает строка «сразу после render» — разметку с заголовком или пустоту.

const root = document.getElementById("root")!;

// это весь HTML, который приехал посетителю
console.log("в разметке:", JSON.stringify(root.innerHTML));

function Hello() {
  return <h1>Список задач</h1>;
}

ReactDOM.createRoot(root).render(<Hello />);

console.log("сразу после render:", JSON.stringify(root.innerHTML));

setTimeout(() => {
  console.log("через 100 мс:", root.innerHTML);
}, 100);

Пусто оба раза. Первый — понятно: скрипт только начался. Второй интереснее: render() ничего не рисует, а ставит работу в очередь — это тот самый триггер из статьи «Триггер, рендер, коммит». Разметка появляется позже, когда React дойдёт до коммита. На странице с настоящим бандлом к этим миллисекундам добавляется скачивание и разбор нескольких сотен килобайт кода.

На ноутбуке разработчика с локальным сервером эти шаги сливаются в один кадр. На телефоне в метро между первым и последним — секунды белого экрана, и каждый шаг ждёт предыдущего: запрос за данными нельзя начать, пока не выполнился код, который его отправляет.

Вторая половина беды в том, что страницу читают не только люди. Карточка ссылки в мессенджере, превью в соцсети, парсер прайсов, поисковый робот — все они берут то, что пришло в HTML. Гуглбот скрипты выполняет, но откладывает это на отдельный проход; остальные чаще всего не выполняют вовсе. В пустом #root им читать нечего.

Проверить чужое приложение просто: «Просмотр кода страницы» в контекстном меню, а не инспектор. Инспектор показывает уже собранное дерево, а исходный код — то самое, что пришло по сети.

Пересчитайте словарь, который вы выучили за эту часть: компоненты, пропсы, состояние, эффекты, контекст, один корень. В нём нет слов «адрес», «сервер», «файл», «сборка». React — библиотека рендеринга: она превращает состояние в дерево узлов и обновляет его. На этом её обязанности заканчиваются.

Это не претензия. Библиотека сознательно не лезет туда, где ответ зависит от проекта: React живёт и в приложении на весь экран, и в одном виджете внутри чужой страницы, и в мобильном React Native, где никакого HTML нет вовсе. Зато и документация React честно советует новое приложение начинать с фреймворка — не из вежливости, а потому что перечисленное всё равно придётся собрать.

А часть пунктов библиотека закрыть и не может. Серверные компоненты, действия сервера, потоковая отдача — это не функции, которые «достаточно вызвать»: они требуют, чтобы кто-то один одновременно владел сборкой, сервером и клиентом, знал, какой кусок кода куда уехал, и умел передать между ними готовый результат. React определяет протокол, а реализует его фреймворк. Поэтому «взять React и добрать нужное по вкусу» упирается не в лень, а в границу возможного.

Возьмём самое частое требование: два экрана и адрес, который можно скинуть коллеге. В React для этого нет ничего — значит, пишем сами. Инструменты знакомы: адрес меняет history.pushState, о нажатой кнопке «назад» сообщает событие popstate на window, а хранить текущий путь будет обычное состояние.

type Route = { path: string; view: () => React.ReactElement };

const routes: Route[] = [
  { path: "/", view: () => <h1>Задачи</h1> },
  { path: "/about", view: () => <h1>О проекте</h1> }
];

function useRoute(): Route | undefined {
  const [path, setPath] = React.useState(() => location.pathname);
  React.useEffect(() => {
    // кнопка «назад» меняет адрес мимо нашего кода — узнать о ней можно
    // только событием, своего вызова navigate тут не было
    const onPop = () => setPath(location.pathname);
    window.addEventListener("popstate", onPop);
    return () => window.removeEventListener("popstate", onPop);
  }, []);
  return routes.find((route) => route.path === path);
}

function navigate(path: string): void {
  history.pushState(null, "", path);
  // pushState событие не порождает — иначе подписчики не узнают о переходе
  window.dispatchEvent(new PopStateEvent("popstate"));
}

console.log(routes.some((route) => route.path === "/about"));
console.log(routes.some((route) => route.path === "/tasks/42"));

Настоящий переход тут не показать: у песочницы нет своего адреса, pushState в изолированном кадре запрещён. Зато сопоставление проверяется без адресной строки — и уже оно ломается на втором вызове.

Вторая строка и есть первая трещина. Адрес /tasks/42 в списке маршрутов не найден, потому что строки сравниваются целиком, а номер задачи заранее неизвестен. Значит, нужен разбор пути на сегменты, потом — параметры запроса после ?, потом — вложенность. Так и начинается свой роутер: с тридцати строк, которые честно работают на двух экранах.

Но даже когда всё это написано, остаётся пункт, который клиентский код не закроет в принципе. Посетитель стоит на /tasks/42 и нажимает F5. Браузер идёт с этим адресом на сервер, сервер ищет такой файл или папку и не находит — 404. Ваш роутер к этому моменту ещё не существует: его код лежит в бандле, а бандл подключён из index.html, который сервер как раз и не отдал.

Лечится это на сервере: отдавать index.html на любой неизвестный адрес. То есть настройкой, которая не живёт нигде в вашем React-приложении — её пишут отдельно в конфиге хостинга, и она первой теряется при переезде. В Next.js этой проблемы не решают, а не создают: маршрут — это папка в проекте, и сервер знает про него из той же файловой структуры. Как именно — следующая статья главы.

Между вашим файлом и браузером обязательно кто-то стоит. Причина первая — синтаксис: <h1>Привет</h1> посреди кода для любого движка JavaScript синтаксическая ошибка, а аннотации типов из части III движок не понимает тем более. И то и другое существует только до сборки.

Причина вторая — импорты. Строку import { useState } from "react" браузер разобрать может, а выполнить нет: голые имена пакетов он без карты импортов — тега, где каждому имени прописан адрес, — не разрешает, ему нужен путь к файлу. Кто-то должен пройти по всем импортам, найти пакеты в node_modules и склеить это в файлы, которые можно отдать по сети.

Эта половина закрывается и без фреймворка: npm create vite даёт сборку, dev-сервер и горячую замену за одну команду, и для виджета, админки или внутренней панели этого правда достаточно. Но Vite намеренно останавливается на границе браузера: он готовит файлы. Кто отдаст первый HTML, что ответит на /tasks/42, где выполнится код, которому нельзя в браузер, — вопросы не к нему. Сервер приносит фреймворк сверху; на том же Vite, кстати, работает и React Router в режиме фреймворка. А в Next.js эту половину закрывает встроенный сборщик Turbopack — как именно, разобрано в главе про сборку.

Главное в Next.js не количество возможностей, а то, что решения уже приняты и одинаковы во всех проектах. Папка app — это карта адресов. Файл page.tsx внутри неё — страница. Компонент по умолчанию выполняется на сервере, а в браузер уезжает только то, что вы туда отправили сами.

Сама страница — обычный компонент, ровно такой же, какие вы писали всю часть. Ни регистрации маршрута, ни конфигурации: важно только имя файла и место в дереве папок.

// app/page.tsx — вся страница по адресу "/" целиком.
// В настоящем файле компонент уезжает наружу через export default;
// песочница выполняет один скрипт, поэтому экспорта здесь нет.
function Page() {
  return <h1>Список задач</h1>;
}

// никакой особой сущности «страница» не появилось: это обычный компонент,
// возвращающий обычный объект — ровно как в первой главе части
console.log(Page().type);

А дальше эта договорённость окупается на каждом пункте из списка, с которого мы начали.

Ни один пункт не магия: каждый делается руками, и раньше именно так и делали. Вопрос в том, сколько из них вы готовы сопровождать сами — и понадобится ли объяснять это тому, кто придёт в проект после вас.

За снятые заботы платят тремя счетами. Первый — сервер: приложение на Next.js по умолчанию не файлы, а процесс Node, который где-то работает, что-то ест и иногда падает. Статический экспорт из главы про кеш и прод возвращает вас к обычным файлам, но вместе с сервером отключается половина возможностей.

Второй счёт — договорённости. Имя файла теперь значит больше, чем его содержимое, и «серверный это компонент или клиентский» становится вопросом к каждому новому файлу. Третий — скорость изменений: Next за несколько лет дважды заметно переучил своих пользователей — сначала переездом на App Router, затем правилами кеширования, — и половина статей в интернете описывает уже не тот фреймворк.

Поэтому фреймворк нужен не всегда. Виджет расчёта доставки, встраиваемый в чужую страницу; админка за логином, которую не индексируют и открывают с рабочего ноутбука; панель внутри Electron или расширения браузера; один интерактивный кусок на в остальном обычном сайте — во всех этих случаях пустой первый HTML никому не мешает, а сервер только добавит хлопот. Vite и роутер отдельным пакетом честнее.

Правило простое. Если страницы должны находиться поиском, открываться по прямой ссылке, быстро показываться на телефоне и собираться из данных, которые нельзя отдавать браузеру, — берите фреймворк. Если приложение и так начинается с формы входа и живёт на одном экране — не берите.

Next.js не единственный: React Router и TanStack Start решают тот же список. В учебнике мы берём Next.js, потому что серверные возможности React обкатываются вместе с ним — и потому что на нём собран сайт, который вы сейчас читаете.