Next.js или React: что выбрать для проекта
Если вы хоть немного пожили в фронтенде, наверняка сталкивались с этим надоевшим выбором — что взять на новый проект: Next.js или просто React? У меня на счету больше десятка реальных запусков — тут и одностраничные лендинги, и чудовищно сложные SaaS-системы, где любой баг стоит приличных нервов. И я слишком хорошо знаю тот момент, когда ты думаешь: «Ну раз все вокруг сели на Next.js, пора и мне!» А потом берёшься разгребать последствия.
Где чистый React реально лучше
Вспоминаю админ-панель для логистической компании — внутренний инструмент, доступ только по паролю. Решил не заморачиваться и завёз туда Next.js. Вроде как современно, круто, SSR под капотом… Но никто не предупредил меня о том цунами лишней настройки и бессмысленных API-роутов (которые дублируют уже работающий бэкенд), плюс возня с гидрацией состояния — всё это вышло боком. После пары недель ругани с командой ушли бы мы в обычный Create React App или Vite — проект явно вздохнул бы спокойнее.
С тех пор у меня чёткое правило. Если делаю штуку вроде SPA-дашборда или CRM — то есть приложение за авторизацией, куда пользователь входит утром и забывает о других вкладках до вечера — беру чистый React. Максимум контроля над архитектурой, никаких «магических» папок pages и ручной сборки роутига под себя. На компоненты или встраиваемые виджеты фреймворк вообще не нужен — тут жонглируешь классическим стэком так, чтобы его спокойно принимали внутри чужого приложения.
Когда без Next.js становится скучно спорить
Но бывает обратная ситуация: например, интернет-магазин с публичным каталогом для клиента из ритейла. Требования жёсткие: Яндекс должен «видеть» карточки товаров сразу, скорость загрузки критична (особенно если у людей дома 3G, а не оптоволокно). Вот тут ни секунды сомнений — нужен SSR/SSG из коробки. Перешли на Next.js — и через три месяца после запуска поисковой трафик вырос почти наполовину! Не потому что там волшебство какое-то; просто паутина наконец увидела нормальный HTML вместо голого div-контейнера.
Как быстро понять, что стоишь на стороне Next.js:
- Страницы должны индексироваться поисковиками (всякие блоги, магазины и маркетплейсы)
- Сильно влияет скорость первой отрисовки; много мобильных пользователей
- Хочется гибкости между SSG/SSR/ISR — например, обновлять разные разделы по-разному
- Команда готова покопаться в новых подходах (App Router пушит всех прямо к server components; такие изменения в мышлении редко проходят за 15 минут)
Мелкие ловушки и болевые точки
Есть нюансы, которые можно ощутить только по ходу дела.
Например — vendor lock-in куда серьёзнее, чем может казаться со стороны. Те же оптимизации картинок или Edge Functions идеально работают только на Vercel (даже самый опытный DevOps позеленеет при попытке собрать тот же комфорт своими руками). Придётся решить заранее: если вашей инфраструктуре нужно жить локально или внутри корпоративного VPN — спросите себя об этом честно ДО старта проекта.
App Router тоже сначала кажется прикольным улучшением навигации… А потом вдруг выясняется: кучу привычных вещей приходится переосмыслять фундаментально. То, что раньше жилo без проблем в useEffect’е или custom hook’ах на клиенте, теперь прячется на сервере вместе со своими state’ами. Любишь predictability Redux-а? Получай сеанс пересборки мозгов.
Отдельная правда о чистом React.
Без видимого фреймворка ты всё равно лепишь свой маленький «фреймворк» из запчастей: Vite для сборки приложений молниеносным образом; React Router ради нормальной маршрутизации; какой-нибудь TanStack Query подговорить с сервером… Даёт свободу и точность под себя (например можно прям слету выбрасывать то, чего точно не будет никогда), но придётся заранее договориться внутри команды о соглашениях и паттернах работы.
Мой собственный чеклист перед стартом любого проекта
Всегда кручу в голове простую тройку вопросов:
- Нужно ли этому проекту SEO или мгновенный FCP? Если да — только Next.js.
- Планируется сложная бизнес-логика на стороне сервера? Тогда опять же проще взять Next.js ради SSR.
- Команда маленькая/новички/надо сделать MVP на вчера без заморочек? Тут лучше собраться вокруг Vite + React Router + пара сбалансированных библиотек.
На что ориентируюсь сейчас
Я больше не воспринимаю Next.js как какую-то эволюцию React-а или обязательное продолжение фронтендерской карьеры. Это отдельный зверь со своими плюсами и злобными капканами. Чистый React (+ свежая сборка типа Vite) нынче годится для любых внутренних приложений; всё работает быстро и прозрачно.
Next.js берём тогда, когда на сцене появляется публичный контент: пусть всё покажется роботу Яндекс уже до загрузки JS-бандлов; пусть страница открывается быстрее моргания даже в деревне с EDGE-интернетом; пусть команда знает куда лезет (а если нет силы вникать – держитесь поближе к стандартному stack’у).
Единственный универсальный рецепт здесь – смотреть не на тренды рынка или советы хайповых блогеров; смотреть туда, где у проекта настоящие бизнес-требования и реальные ограничения команды. Ну а дальше делать выбор не потому что «так модно», а потому что это работает именно здесь и сейчас – лично для вас и ваших задач.