Next.js по умолчанию — почему агентства теряют деньги, выбирая фреймворк «как все»

Satisfaction у Next.js рухнул с 68% до 55% за год — рекордное падение среди всех JS-фреймворков. При этом 59% разработчиков продолжают его использовать. Знакомая ситуация: инструмент выбирают не потому что подходит, а потому что «так принято». Для бизнеса это означает конкретные потери — в деньгах, сроках и предсказуемости.

Я руковожу разработкой в агентстве и за последние два года видел десятки проектов, где Next.js был выбран на старте без обсуждения. Просто потому что «все знают React, а Next.js — это React с серверным рендерингом». Звучит логично. На практике — создаёт проблемы, которые не видны на этапе пресейла, но больно бьют по марже.

Давайте разберём, когда этот выбор оправдан, а когда вы закладываете технический долг с первого коммита.

В нулевых Java EE была ответом на любой вопрос про enterprise. Мощная, зрелая, с экосистемой. И абсолютно избыточная для 80% проектов. Next.js в 2025–2026 занял ту же нишу.

По данным State of JavaScript 2025, 17% разработчиков, использующих Next.js, настроены негативно — они работают с инструментом, который их не устраивает. Разрыв в удовлетворённости с лидером рейтинга Astro — 39 процентных пунктов. Это разница между «нравится» и «терплю».

Для агентства или продуктовой компании выбор стека — не вопрос вкуса. Это решение, которое определяет:

Выбрать Next.js по инерции — значит принять все эти риски, даже не осознав их.

App Router — ключевое нововведение Next.js последних версий. По сути, это второй фреймворк внутри фреймворка. Pages Router и App Router настолько различаются, что разработчик с годом опыта на старой версии проходит полноценное переобучение.

Что это значит для бизнеса? Конкретный пример: мидл-разработчик получает задачу — форма обратной связи с валидацией. На чистом React — два часа работы. На Next.js с App Router он сталкивается с каскадом вопросов: Server Component или Client Component? Где граница? Почему теряется контекст? Что за hydration error?

Полдня уходит не на бизнес-логику, а на борьбу с архитектурой фреймворка.

Мы видели устойчивый паттерн: разработчики среднего уровня, столкнувшись с ошибками гидратации, просто оборачивают весь компонент в 'use client'. Код формально работает. Фактически — все преимущества серверных компонентов исчезают, а сложность остаётся. Это когнитивная нагрузка, которая не фиксируется в трекере задач, но накапливается как долг.

Отдельная проблема — агрессивное кэширование. Разработчик думает, что делает запрос к API, а фреймворк тихо возвращает кэшированный результат. Отладка требует глубокого знания внутренностей Next.js, которого нет у большинства команд.

Vercel — отличная платформа. Проблема в том, что Next.js всё теснее к ней привязан, а Vercel — не бесплатный.

Конкретные цифры:

Для агентства с десятком клиентских проектов это арифметика с шестью нулями в год.

При self-hosting сюрпризы не заканчиваются. В Next.js 15.1.8 изменилось поведение metadata streaming: для не-Vercel деплоев метаданные отправляются отдельно после загрузки страницы и требуют JavaScript. Для SEO-ориентированных проектов — прямой удар по позициям в поиске.

Docker-образ минимального проекта на Next.js (15 страниц вёрстки) весит 600+ МБ. В GitHub Discussions с 2021 по 2026 год — шесть тредов про утечки памяти в Docker/Kubernetes, где процесс линейно наращивает потребление до OOM-краша.

В 2025 году вскрылись две критические уязвимости:

Для одного проекта это обновление за пару часов. Для агентства с десятью проектами на разных версиях (12, 13, 14, 15) — массовый ручной труд. Каждая мажорная версия имеет свои breaking changes, и обновление с 13 до 15 — это не npm update, а рефакторинг.

Этот версионный хаос в агентском портфеле практически нигде не описан, но именно он превращает одну CVE в неделю работы.

1. Команда меньше трёх человек. App Router требует 2–4 недели погружения. Для пары разработчиков на проекте с жёстким дедлайном — четверть бюджета времени уходит на изучение фреймворка, а не на продукт.

2. Проект без сложных SEO-требований. Дашборд за авторизацией, корпоративный портал, внутренний инструмент — серверный рендеринг здесь не нужен. Обычный SPA решает задачу проще и без сюрпризов.

3. Фиксированный бюджет и жёсткие сроки. Next.js увеличивает дисперсию оценок. Задача, которая на простом стеке предсказуемо займёт 8 часов, на Next.js может занять 8 или 20 — зависит от того, наткнётся ли разработчик на edge-кейс. Для агентства с фиксированной ценой контракта — прямой финансовый риск.

Было бы нечестно списывать фреймворк целиком. Next.js — правильный выбор в конкретных сценариях:

Несколько показательных кейсов миграции:

Эти истории не про то, что Next.js плох. Они про то, что он был выбран для задач, где не нужен.

Перед стартом каждого проекта мы проходим простой чек-лист:

Эти пять вопросов занимают 30 минут и экономят месяцы.

Next.js — мощный инструмент. Но мощность без необходимости — это не преимущество, а накладные расходы. Для CTO и продакт-менеджера выбор стека — одно из самых влиятельных решений на проекте. Оно определяет скорость команды, предсказуемость сроков, стоимость поддержки и отношения с клиентом.

Принимать это решение «по умолчанию» — значит не принимать его вовсе.

А как вы выбираете стек для новых проектов — по привычке или по чек-листу?

https://vibelab.ru

Подписывайся на Телеграм Вайблаб, чтобы наблюдать за тем, как мы строим AI-first компанию.

Напишите нам напрямую