В каких типах frontend-проектов Nuxt даёт реальный выигрыш, а где будет избыточен или неудачен?

Где Nuxt даёт реальный выигрыш

Nuxt оправдывает себя в проектах, где важны SEO, первоначальная скорость загрузки и структурированная командная работа на Vue. Конкретные случаи:

• Контентные сайты и блоги — Nuxt Content + статическая генерация (SSG) даёт идеальный Lighthouse-score и мгновенный TTFB с CDN без серверной инфраструктуры.
• Маркетинговые лендинги с Vue — гибридный рендеринг позволяет генерировать маркетинговые страницы статически, а личный кабинет — на стороне сервера.
• E-commerce с Vue — SSR критичен для SEO карточек товаров и Core Web Vitals; Nuxt Image + автоматическая оптимизация закрывают большинство performance-задач из коробки.
• Корпоративные порталы — file-based routing, layouts, middleware для auth сокращают boilerplate и позволяют новым разработчикам быстро ориентироваться.
• Fullstack Vue-проекты — server routes (server/api/) на Nitro позволяют держать BFF и фронтенд в одном репозитории без отдельного Express/Fastify.

Где Nuxt избыточен

• Внутренние дашборды и admin-панели без требований к SEO — SPA на Vite + Vue Router проще, быстрее стартует и не тащит серверные зависимости.
• Micro-frontend-архитектуры — Nuxt плохо дружит с Module Federation из-за своего слоя авто-импортов и virtualных модулей.
• Мобильные приложения через Capacitor/Ionic — SSR здесь бессмысленен, а лишняя сложность Nuxt мешает.

Где Nuxt неудачен

• Команды без опыта Vue — если команда знает React, Next.js даст те же преимущества без переобучения. Nuxt не компенсирует кривую обучения Vue для React-разработчиков.
• Очень кастомный server-side — если бэкенд уже есть на Go/Python и нужен только фронтенд, SSR Nuxt добавляет Node.js-сервер без очевидной пользы.
• Realtime-heavy приложения (чаты, live-collaboration) — SSR не даёт преимуществ, а socket-логика плохо вписывается в модель server routes Nitro.

Подводные камни

• Переход с Nuxt 2 на Nuxt 3 — ломающее изменение. Options API, Vuex и многие плагины требуют полной переработки.
• Nitro в production добавляет Node.js runtime — нельзя деплоить как чистый статический сайт без явного nuxi generate.
• Модули экосистемы Nuxt 3 ещё не покрывают все ниши Nuxt 2: часть популярных плагинов требует ручной адаптации.
• File-based routing создаёт жёсткую связь между URL-структурой и файловой системой — рефакторинг маршрутов затруднён без переименования файлов.
• Гибридный рендеринг (разные режимы для разных маршрутов) сложен в отладке: легко случайно деоптимизировать страницу, добавив один динамический хук.
• Vendor lock-in на Nuxt-экосистему: замена на Vite SPA потребует переработки server routes, middleware и composable.
• Авто-импорты скрывают зависимости — в крупных проектах сложно понять, откуда берётся конкретная функция без DevTools или LSP.

• Выбирать Nuxt по популярности, а не по требованиям проекта
• Игнорировать опыт команды, эксплуатацию и стоимость поддержки
• Не называть ситуации, где Nuxt будет плохим выбором

• Называет критерии выбора Nuxt
• Учитывает команду, эксплуатацию, стоимость и риски
• Может назвать сценарии, где выбрал бы альтернативу