Next.js или чистый React — что лучше

React даёт свободу, Next.js даёт готовую архитектуру. Проблема в том, что свобода иногда превращается в “а теперь собери себе фреймворк сам”.

На практике выбор между Next.js и чистым React обычно появляется не в момент “что бы мне поизучать вечером”, а когда проект начинает пахнуть реальной жизнью. Нужны страницы, SEO, нормальная загрузка, личный кабинет, каталог, блог, админка, API, авторизация — и внезапно простой React-приложение превращается в набор решений, которые нужно склеивать руками.

React сам по себе — это библиотека для интерфейсов. Он отлично отвечает на вопрос: “как построить UI из компонентов”. Но он не говорит, как именно делать маршруты, серверный рендеринг, работу с метаданными, загрузку данных, оптимизацию изображений и структуру проекта. Next.js закрывает как раз эту боль: это React-фреймворк, который добавляет маршрутизацию, серверный рендеринг, статическую генерацию, Server Components и другие вещи из коробки. В официальной документации Next.js прямо описан как React framework для веб-приложений, а App Router использует современные возможности React вроде Server Components, Suspense и Server Functions.

Основная часть

Если говорить совсем по-человечески, чистый React — это как купить хороший двигатель. Мощный, гибкий, можно собрать что угодно. Но коробку передач, кузов, приборку и ремни безопасности ты выбираешь сам. Next.js — это уже машина в сборе. Да, не всегда идеально под твой вкус, зато можно ехать, а не три недели спорить с командой, как назвать папку routes.

Чистый React чаще всего используют для SPA — single page application. Браузер получает почти пустой HTML, загружает JavaScript, а уже потом React рисует интерфейс. Для личного кабинета, админки, CRM, панели управления или внутреннего инструмента это нормально. Пользователь всё равно авторизуется, SEO там обычно не критично, а интерфейс живёт как приложение.

Но для публичного сайта всё становится интереснее. Интернет-магазин, блог, медиа, лендинг, каталог услуг, сайт с документацией — здесь важны первая загрузка, индексация, метатеги, превью в соцсетях. В клиентском рендеринге браузер сначала скачивает минимальный HTML и JavaScript, и только после выполнения JS пользователь видит полноценную страницу. В документации Next.js отдельно отмечается, что при CSR может быть задержка до отображения полного контента.

Вот здесь Next.js обычно выигрывает. Он умеет отдавать готовый HTML с сервера, генерировать статические страницы, комбинировать серверные и клиентские компоненты. В App Router страницы и layout по умолчанию являются Server Components: они могут получать данные и рендериться на сервере, а интерактивные части выносятся в Client Components.

И это не просто модная архитектурная игрушка. Меньше JavaScript на клиенте — меньше работы для браузера. Особенно на слабых ноутбуках и телефонах. А пользователи, как назло, не всегда сидят на MacBook Pro с идеальным интернетом.

Когда лучше выбрать чистый React

Чистый React хорош, когда тебе не нужен серверный рендеринг и сложная SEO-история. Например, ты делаешь админку для менеджеров, внутреннюю CRM, дашборд аналитики, визуальный редактор, таск-трекер или приложение, где почти всё скрыто за авторизацией.

В таких проектах Next.js иногда ощущается лишним слоем. Ты хотел быстро собрать интерфейс, а получил вопросы про серверные компоненты, кеширование, use client, layout-структуру и особенности деплоя. Не смертельно, но для простой админки это может быть как ставить турбину на самокат.

На чистом React с Vite можно быстро стартовать, подключить React Router, TanStack Query, Zustand или Redux Toolkit, настроить API-клиент и спокойно жить. Особенно если backend уже существует отдельно, а frontend просто общается с ним по REST или GraphQL.

Пример простой структуры React-приложения:

src/
  app/
    App.tsx
    router.tsx
  pages/
    DashboardPage.tsx
    UsersPage.tsx
  features/
    users/
      api.ts
      hooks.ts
      UsersTable.tsx
  shared/
    ui/
    api/

Здесь всё понятно: React отвечает за интерфейс, роутер — за страницы, API-клиент — за запросы. Никакой магии. Иногда это именно то, что нужно.

Когда лучше выбрать Next.js

Next.js лучше брать, когда проект публичный и ему важно нормально жить в интернете. Сайт компании, блог, маркетплейс, интернет-магазин, каталог, образовательная платформа, медиа, документация — всё это хорошие кандидаты.

Главная польза Next.js не в том, что он “модный”. Польза в том, что многие скучные, но важные вещи уже продуманы: маршруты через файловую систему, серверный рендеринг, статическая генерация, работа с метаданными, оптимизация изображений, layout-структура, API route handlers. Next.js берёт на себя часть архитектурной рутины, которую на чистом React пришлось бы собирать отдельно.

Простой пример страницы товара в Next.js:

// app/products/[slug]/page.tsx

type ProductPageProps = {
  params: Promise<{
    slug: string;
  }>;
};

async function getProduct(slug: string) {
  const response = await fetch(`https://api.example.com/products/${slug}`, {
    // На практике здесь важно продумать кеширование,
    // иначе можно случайно показывать старые цены.
    cache: 'no-store',
  });

  if (!response.ok) {
    throw new Error('Product not found');
  }

  return response.json();
}

export async function generateMetadata({ params }: ProductPageProps) {
  const { slug } = await params;
  const product = await getProduct(slug);

  return {
    title: `${product.name} — купить в магазине`,
    description: product.shortDescription,
  };
}

export default async function ProductPage({ params }: ProductPageProps) {
  const { slug } = await params;
  const product = await getProduct(slug);

  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <strong>{product.price} ₽</strong>
    </main>
  );
}

Пояснение простое: страница получает данные на сервере, формирует HTML и метаданные. Для SEO это намного приятнее, чем ситуация, когда поисковик сначала видит пустой div, а потом надеется, что JavaScript всё дорисует.

Где чаще всего ошибаются

Самая частая ошибка — брать Next.js “потому что все берут”. Потом человек делает обычную админку, везде пишет 'use client', загружает данные через useEffect, а от Next.js остаётся только более сложная структура проекта. В этот момент хочется тихо спросить: зачем мы вообще сюда пришли?

Вторая ошибка — думать, что Next.js автоматически делает проект быстрым. Нет. Если засунуть половину приложения в клиентские компоненты, тащить тяжёлые библиотеки в браузер и не понимать кеширование, можно получить красивый, современный, но тормозящий комбайн. Server Components помогают уменьшать клиентский JavaScript, но только если архитектура действительно серверная там, где это уместно.

Третья ошибка — выбирать чистый React для сайта, где важны SEO и первая загрузка. Конечно, можно потом прикрутить SSR, prerender, костыли для метатегов и отдельные решения для оптимизации. Но это уже тот момент, когда ты постепенно изобретаешь свой маленький Next.js. Обычно не самый лучший.

Что выбрать в итоге

Если проект — публичный сайт, блог, каталог, интернет-магазин, платформа с SEO-страницами или что-то, что должно быстро открываться и хорошо индексироваться, я бы выбирал Next.js.

Если проект — закрытая админка, CRM, внутренний сервис, интерактивная панель или приложение, где SEO не играет роли, чистого React с Vite чаще всего достаточно.

React — это не “хуже”. Next.js — это не “всегда лучше”. Просто они решают задачи разного уровня. React даёт UI-базу. Next.js даёт готовую инфраструктуру вокруг React.

Вывод

Мой практический ориентир такой: если пользователь приходит из поиска, открывает отдельные страницы и должен быстро увидеть контент — Next.js. Если пользователь сначала логинится, а потом работает внутри интерфейса как в приложении — чистый React.

И да, перед выбором лучше честно ответить не на вопрос “что популярнее”, а на вопрос “какую боль я сейчас решаю”. Потому что самая дорогая технология — не та, у которой высокий порог входа, а та, которую выбрали не под задачу.