Nuxt, Next.js, Astro или SvelteKit: какой фронтенд-фреймворк выбрать для проекта

Спор о лучшем фронтенд-фреймворке обычно начинается не с того вопроса. Команды сравнивают скорость сборки, количество звёзд на GitHub или результаты пустого шаблона в Lighthouse. Но заказчик покупает не шаблон. Ему нужен интернет-магазин с обменом с 1С, личный кабинет с ролями, корпоративный сайт с редакторами или сервис, в котором пользователь проводит весь рабочий день.

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

Мы используем все четыре подхода: Nuxt в крупных каталогах и e-commerce, Next.js в сложных B2B-платформах и React-продуктах, Astro в фестивальных сайтах и на panfilov.digital, SvelteKit во внутренних сервисах, а Svelte — для интерактивных компонентов внутри Astro. Ниже — модель выбора по типу проекта вместо синтетического рейтинга.

Сначала уточним термины

Nuxt, Next.js, Astro и SvelteKit — фреймворки для приложений. Они дают маршрутизацию, серверный рендеринг, загрузку данных, сборку и способы деплоя.

Svelte устроен немного иначе: это компилятор UI-компонентов. Он превращает декларативные компоненты в оптимизированный JavaScript. Полноценный аналог Nuxt или Next.js в этой экосистеме — SvelteKit. В разговоре его часто сокращают до «Svelte», но при выборе архитектуры разница важна. В статье под Svelte как вариантом для целого проекта мы подразумеваем SvelteKit.

Есть ещё одно важное различие:

• Nuxt строится вокруг Vue;
• Next.js — вокруг React;
• SvelteKit — вокруг Svelte;
• Astro не требует одного UI-фреймворка и может подключать компоненты React, Vue, Svelte, Preact и других библиотек как отдельные интерактивные острова.

Все четыре инструмента умеют отдать поисковому роботу готовый HTML. Все могут работать с API и headless CMS. Все можно развернуть не только на облачной платформе автора, но и на собственном сервере. Поэтому утверждения «этот фреймворк для SEO, а этот нет» или «Next.js работает только на Vercel» давно устарели.

Отдельно мы разобрали, как устроена headless-архитектура интернет-магазина и когда разделение фронтенда и бэкенда окупает дополнительную сложность.

Главное отличие: архитектура по умолчанию

Выбор определяет архитектура по умолчанию: какой код выполняется на сервере, сколько JavaScript попадает в браузер и где проходит граница интерактивности.

Nuxt и SvelteKit обычно сначала рендерят страницу на сервере, а затем гидратируют её в браузере: связывают HTML с JavaScript, чтобы интерфейс стал интерактивным. Next.js App Router разделяет дерево на серверные и клиентские React-компоненты. Astro по умолчанию вообще не отправляет JavaScript для компонента, пока разработчик явно не пометит его как интерактивный.

Из этого следуют разные компромиссы:

Ни один столбец сам по себе не определяет победителя. Для новостного сайта отсутствие JavaScript по умолчанию — преимущество. Для конструктора товаров, дашборда или кабинета с десятками взаимосвязанных состояний острова могут стать искусственным ограничением.

Nuxt: e-commerce и каталоги в Vue-экосистеме

Nuxt — полноценный фреймворк вокруг Vue с клиентским и серверным слоями. По умолчанию он использует универсальный рендеринг: сервер отдаёт готовый HTML, затем Vue гидратирует страницу в браузере. Через routeRules можно смешивать разные режимы: заранее генерировать одни страницы, кэшировать другие и рендерить динамические разделы на каждый запрос. Серверный движок Nitro даёт API-маршруты, промежуточные обработчики и сборку под Node.js, бессерверные и edge-платформы или статический хостинг.

Для прикладной разработки важны не только режимы рендеринга, но и конвенции. Nuxt автоматически собирает маршруты из файлов, импортирует компоненты и composables, разделяет серверный и клиентский код. useFetch и useAsyncData передают загруженные на сервере данные в браузер, чтобы не повторять тот же запрос во время гидратации.

Когда Nuxt подходит лучше всего

• большой каталог или интернет-магазин;
• B2B-витрина с фильтрами, корзиной, персональными ценами и кабинетом;
• корпоративный сайт, который постепенно превращается в сервис;
• продукт на Vue или проект команды с сильной Vue-экспертизой;
• приложение, где много интерактивности, но поисковая индексация публичной части остаётся критичной;
• долгоживущий проект с собственным API бэкенда, 1С, ERP или CRM.

Плюсы Nuxt

Понятная модель компонентов. Vue Single File Components держат шаблон, логику и стили рядом. Для многих команд эта модель проще React-композиции с серверными и клиентскими границами.

Хороший баланс между сайтом и приложением. Можно начать с контентных страниц, а затем добавить каталог, кабинет, корзину и серверные маршруты, не меняя основной фреймворк.

Гибридный рендеринг по URL. Карточки и статьи можно пререндерить или кэшировать, кабинет оставить динамическим, а служебный раздел сделать клиентским приложением.

Nitro как переносимый серверный слой. Nuxt не требует конкретного облака. Сборку можно запускать в Docker на обычном VPS, что важно для проектов с требованиями к инфраструктуре и размещению данных.

Зрелая экосистема Vue. Есть готовые решения для интерфейсов, форм, состояния, локализации, аналитики и CMS. При этом Nuxt оставляет возможность писать собственную архитектуру поверх API бэкенда.

Минусы Nuxt

Гидратацию нельзя игнорировать. Код выполняется в двух средах. Обращение к window, случайное расхождение данных сервера и браузера или библиотека с побочными эффектами легко приводят к hydration mismatch.

Лишний JavaScript появляется незаметно. Если весь интерфейс строится как Vue-приложение, даже почти статические страницы могут получить клиентский код, который им не нужен. Это не фатальный недостаток, но требует контроля состава клиентской сборки и границ интерактивности.

Конвенции скрывают механику. Автоимпорты и composables ускоряют разработку, пока команда понимает жизненный цикл данных. Ошибки с ключами useAsyncData, повторными запросами и состоянием между маршрутами могут быть неочевидны.

Большая миграция между поколениями — отдельный проект. Наш опыт перехода крупных систем с Nuxt 2 показывает: если приложение накопило много Vue 2-зависимостей и собственной логики, механическое обновление редко оказывается дешевле осознанного перепроектирования.

Наши кейсы на Nuxt

Nuxt — один из наших проверенных стеков для крупных проектов в e-commerce и B2B.

В Delasia Nuxt 4 работает как фронтенд промышленного каталога на 600 000+ позиций. После MVP проект вырос до поиска на Typesense, страниц 1 419 брендов, 275 000 сгенерированных описаний и расчёта цен по курсу. Здесь важно одновременно индексировать длинный хвост каталога и поддерживать быстрые фильтры, поиск и прикладную логику.

В «Нержавейке.ру» на Nuxt 4 сделаны каталог металлопроката, корзина-заявка, калькулятор веса, подбор продукции и обмен с 1С. Это типичный случай, когда сайт постепенно становится отраслевым приложением, но публичные страницы и SEO не теряют значения.

В «Аквилоне» Nuxt стал частью экосистемы интернет-магазина для сети строительных гипермаркетов вместе с бэкендом на Symfony и MongoDB, мобильным приложением и интерфейсом менеджеров. Такой проект показывает сильную сторону Nuxt: он не диктует устройство всей системы и хорошо работает как отдельная витрина над сложным интеграционным контуром.

Ещё два показательных сценария — закрытый B2B-магазин Segura с персональными ценами, резервированием остатков и обменом с 1С и платформа мероприятий «Петровича», которую мы перенесли с 1С-Битрикс на Nuxt 4 и Directus.

Наш вывод по Nuxt: выбираем его для сбалансированного публичного продукта с большим каталогом, SEO, интеграциями и заметной долей интерактивности.

Next.js: e-commerce и сложные продукты в React-экосистеме

Next.js App Router строится вокруг React Server Components. Страницы и макеты по умолчанию выполняются на сервере: они могут читать данные рядом с источником, использовать секреты и не добавлять собственный JavaScript в клиентскую сборку. Интерактивность включается через Client Components с директивой 'use client'.

В App Router обычный SSR дополняют границы серверных и клиентских компонентов. Дерево может состоять из статических, кэшируемых и динамических частей, а Suspense позволяет отправлять интерфейс потоково. Route Handlers и Server Functions дают серверный слой для форм, мутаций и BFF — прослойки между браузером и внутренними API.

Архитектура мощная, но требует дисциплины. Разработчик должен понимать, где выполняется компонент, какие данные сериализуются, что кэшируется и когда результат инвалидируется.

Когда Next.js подходит лучше всего

• личный кабинет или продукт с большим количеством пользовательских сценариев;
• сложный e-commerce, где React-экосистема и готовые библиотеки дают преимущество;
• приложение с персонализацией, авторизацией, серверными мутациями и потоковой загрузкой;
• проект, в котором фронтенд одновременно играет роль BFF между браузером, CMS, CRM и другими API;
• команда уже работает на React и хочет использовать общие компоненты, знания и инструменты;
• CMS или бэкенд тесно интегрируется в Node.js-приложение.

Плюсы Next.js

Серверные компоненты по умолчанию. Доступ к базе, CMS или внутреннему API можно оставить на сервере, а в браузер передать только результат и JavaScript действительно интерактивных частей.

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

React-экосистема. Если проекту нужны сложные таблицы, редакторы, диаграммы, конструкторы или дизайн-система, выбор совместимых библиотек обычно широк.

Потоковый рендеринг и частичная загрузка. Медленный блок не обязан задерживать всю страницу. При грамотных Suspense-границах пользователь раньше получает рабочую оболочку.

Можно развернуть на своей инфраструктуре. next start и Docker подходят для обычного сервера. Привязка к Vercel не обязательна.

Минусы Next.js

Высокая концептуальная плотность. Server Components, Client Components, Server Functions, статический и динамический рендеринг, Suspense, кэш функций и инвалидирование — это несколько связанных моделей, а не одна настройка SSR.

Граница 'use client' легко разрастается. Если поставить её слишком высоко в дереве, в браузер уедут компоненты и зависимости, которые могли остаться серверными. Польза Server Components зависит от архитектуры, а не появляется автоматически.

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

Фреймворк развивается быстро. Большой проект должен фиксировать поддерживаемые паттерны и не переносить каждую новую возможность в продакшен только потому, что она появилась в документации.

Наш кейс на Next.js

В одном из проектов мы переносим крупную B2B-платформу с Nuxt 2 на Next.js 16, React 19 и Payload CMS. У старой версии 262 компонента страниц, сложный каталог с конфигуратором товаров, корзина, профиль, расчёт цен, оформление заказов, поиск и интеграция с действующей CRM на ASP.NET Core.

Причина выбора Next.js здесь не в том, что он «лучше Nuxt». Целевая архитектура объединяет App Router и встроенный Payload в одном приложении: Server Components читают контент и каталог через Local API, серверные маршруты изолируют CRM, а интерактивные React-компоненты отвечают за корзину, редакторы и оформление заказа. Для этой конкретной модели единый TypeScript-контур и серверно-клиентское разделение Next.js дают больше пользы, чем островная архитектура.

Наш вывод по Next.js: он особенно хорош, когда сайт уже нельзя честно назвать просто сайтом. Но мощность App Router окупается только при явных правилах данных, кэша и границ сервера и клиента.

Astro: контент сначала, интерактивность — по необходимости

Astro начинает не с приложения, а с HTML. Компоненты Astro по умолчанию рендерятся в статическую разметку без клиентского JavaScript. Если блоку нужна интерактивность, разработчик подключает React-, Vue- или Svelte-компонент и явно задаёт момент гидратации: сразу, в свободное время браузера, при появлении в области просмотра или по другому условию.

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

Помимо статических лендингов Astro умеет SSR, серверные API-маршруты, промежуточные обработчики и смешивание заранее собранных и динамических маршрутов. Его архитектурная норма остаётся прежней: сначала решить, можно ли отдать HTML, и только потом добавлять JavaScript.

Когда Astro подходит лучше всего

• корпоративный сайт, медиа, блог или документация;
• фестивальный, образовательный или событийный портал;
• маркетинговый сайт с CMS и несколькими интерактивными блоками;
• каталог без сложной персонализации и общего клиентского состояния;
• проект, где скорость первого показа и минимальный JavaScript важнее SPA-переходов;
• постепенная миграция, при которой нужно использовать компоненты из разных UI-экосистем.

Плюсы Astro

Минимум JavaScript по умолчанию. Статический компонент не требует специальной оптимизации, чтобы остаться статическим. Разработчик должен явно включить клиентское выполнение.

Естественная модель для CMS. Данные можно получить на сборке или во время SSR и сразу превратить в готовый HTML. Статьи, карточки, программы и SEO-метаданные не зависят от выполнения JavaScript в браузере.

Свобода UI-фреймворка. В один проект можно встроить Svelte для фильтров, React для сложного виджета или Vue-компонент из существующей библиотеки. Мы не рекомендуем смешивать технологии без причины, но для миграции и переиспользования это полезно.

Простая эксплуатация статического режима. Собранный сайт можно раздавать как файлы через CDN или nginx. Нет процесса рендеринга, который должен выдерживать каждый запрос.

SSR включается там, где он нужен. Формы, персонализированные страницы и API-маршруты не требуют отказа от Astro целиком.

Минусы Astro

Острова не заменяют архитектуру приложения. Если почти каждый блок интерактивен, зависит от общего состояния и должен мгновенно реагировать на соседние блоки, проект начинает спорить с исходной моделью Astro.

Состояние между островами требует решения. Изолированные компоненты могут общаться, но это дополнительный архитектурный выбор. В едином Vue-, React- или Svelte-приложении такой сценарий часто естественнее.

Не все интеграции рассчитаны на HTML с серверным приоритетом. Некоторые UI-библиотеки предполагают единую клиентскую среду выполнения. Их можно подключить, но тогда часть преимуществ Astro исчезает.

Статическая сборка имеет цену. Если CMS содержит сотни тысяч часто меняющихся страниц, полная пересборка может стать узким местом. Тогда нужны SSR, выборочный пререндеринг, кэширование или другой фреймворк.

Наши кейсы на Astro

На Astro SSR и Directus мы собрали три фестивальных сайта: «Новое Движение», «Дух огня» и Международный фестиваль театральных искусств имени Ф. М. Достоевского. В них есть программы, расписания, фильмы и спектакли, новости, архивы, персоналии, галереи и формы аккредитации.

Это не одноразовые лендинги. Контент резко меняется перед фестивалем и во время него, редакторы работают через CMS, а публичная часть должна быстро открываться на мобильном интернете. Astro подходит, потому что основная ценность страницы — структурированный контент, а не непрерывное клиентское состояние.

Сам panfilov.digital тоже собран на Astro. Страницы, кейсы и блог генерируются из Directus, изображения оптимизируются во время сборки, а Svelte подключается только для фильтра портфолио, видео и анимаций при прокрутке. Это показательный гибрид: Astro отвечает за документ, Svelte — за поведение тех частей, которым оно действительно нужно.

Наш вывод по Astro: фреймворк отдаёт приоритет контенту с точечной интерактивностью. Когда содержание занимает 80% продукта, а интерактивность — 20%, его архитектурный дефолт обычно совпадает с задачей.

SvelteKit: интерактивное приложение с компактным UI-кодом

Svelte переносит заметную часть работы из среды выполнения браузера в компилятор. Компонент пишется как HTML, CSS и JavaScript, а на сборке превращается в компактный код обновления интерфейса. SvelteKit добавляет файловую маршрутизацию, серверную загрузку данных, действия (actions), API-маршруты и адаптеры для разных сред.

По умолчанию SvelteKit рендерит страницу на сервере, отправляет HTML, гидратирует её в браузере и перехватывает последующую навигацию. При этом режим можно менять по разделам: пререндерить маркетинговые страницы, оставить SSR для динамики, превратить закрытый кабинет в SPA или отключить клиентский JavaScript на странице, где он не нужен.

Когда SvelteKit подходит лучше всего

• внутренний сервис, кабинет или дашборд;
• приложение с большим количеством локальных взаимодействий и анимаций;
• продукт небольшой сильной команды, которая контролирует весь стек;
• быстрый MVP, который должен остаться поддерживаемым после проверки гипотезы;
• интерфейс поверх собственного API или Directus;
• проект, где React-экосистема не является обязательным условием.

Плюсы SvelteKit

Короткий и прямой UI-код. Реактивное состояние, вычисления, события и переходы требуют меньше обвязки. В интерфейсах с большим количеством небольших взаимодействий это заметно ускоряет работу.

Компиляторная модель Svelte. В браузер не нужно переносить всю механику виртуального DOM. Это не гарантирует быстрый продукт автоматически, но даёт хороший базовый профиль для интерактивных компонентов.

Гибкость рендеринга по маршрутам. SSR, пререндеринг и CSR можно комбинировать внутри одного приложения. Страницы без интерактивности способны вообще не отправлять JavaScript.

Удобный клиент-серверный контур. Серверные load-функции, actions и API-обработчики находятся рядом с маршрутами. Для небольшого продукта часто не нужен отдельный BFF.

Хорошо работает и как целое приложение, и как остров. Svelte-компоненты можно использовать внутри Astro, не переводя весь сайт на SvelteKit.

Минусы SvelteKit

Экосистема меньше React и Vue. Для стандартного UI всего достаточно, но в редких корпоративных сценариях — сложные редакторы, отраслевые компоненты, специфическая аналитика — выбор библиотек уже. Иногда выгоднее взять React именно ради проверенного компонента.

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

Простота компонента не создаёт архитектуру продукта. В большом приложении всё равно нужны правила для данных, прав доступа, ошибок, серверного состояния и модульных границ.

Новая реактивная модель требует обучения. Svelte 5 использует runes. Они делают зависимости явнее, но разработчикам со старым Svelte или только React/Vue нужно время на адаптацию.

Наши кейсы на Svelte и SvelteKit

SvelteKit мы используем в Content Hub — внутреннем приложении для подготовки и публикации контента OnReport. Оно показывает календарь, этапы процесса, результаты проверок, версии материалов и аналитику, а серверные маршруты связывают Directus, LLM-процессы и публикационные API. Здесь интерфейс интерактивен, но продукт остаётся компактным и принадлежит одной небольшой команде — хороший сценарий для SvelteKit.

На panfilov.digital Svelte решает другую задачу: работает внутри Astro как набор независимых островов. Фильтр проектов, видео на первом экране и появление элементов при прокрутке получают реактивность и анимацию, а статья или страница кейса не превращается из-за этого в единое клиентское приложение.

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

Какой фреймворк выбрать для конкретного проекта

Интернет-магазин или B2B-каталог

Для интернет-магазина нет одного базового выбора между Nuxt и Next.js.

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

Nuxt подходит Vue-команде, публичному каталогу и архитектуре с отдельным бэкендом или учётной системой. Это наш проверенный сценарий для каталогов на сотни тысяч позиций.

Next.js подходит React-команде и e-commerce с персонализацией, сложными интерфейсами, серверными мутациями или CMS внутри Node.js-контура.

Astro подходит витрине или небольшому каталогу, но не должен выбираться только ради высокой оценки Lighthouse, если через полгода появятся сложная корзина, кабинет и единое клиентское состояние.

Корпоративный, медийный или фестивальный сайт

Базовый выбор — Astro. Большая часть страниц состоит из контента, CMS и SEO-метаданных; интерактивные элементы можно выделить в острова.

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

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

Личный кабинет, SaaS или внутренний сервис

Отдельно мы разобрали B2B-порталы и личные кабинеты: какие задачи они решают и где дают бизнесу измеримый эффект.

Next.js подходит большому продукту на React с несколькими командами, широкой компонентной базой, SSR-публичной частью и насыщенным BFF.

SvelteKit особенно хорош для компактного продукта одной команды, где много интерактивности, а библиотеки только для React не определяют архитектуру.

Nuxt остаётся сильным вариантом для Vue-команды. Если индексация кабинета не нужна, закрытый раздел можно рендерить на клиенте, не отказываясь от SSR публичных страниц.

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

Лендинг или быстрый MVP

Для контентного лендинга — Astro. Для MVP интерактивного сервиса — SvelteKit, Nuxt или Next.js в зависимости от будущей команды и библиотек.

Самая дорогая ошибка — выбрать инструмент, на котором быстрее собрать первый экран, но неудобно реализовывать основную механику продукта. Скорость MVP измеряется не временем до красивого прототипа, а временем до проверяемого бизнес-сценария.

Вопросы, которые важнее названия фреймворка

Перед выбором мы отвечаем минимум на семь вопросов.

1. Какая доля интерфейса интерактивна? Не количество кнопок, а наличие общего состояния между блоками.
2. Какие страницы должны индексироваться? Публичный каталог, статьи и карточки требуют готового HTML; закрытый кабинет — нет.
3. Где находится источник истины? CMS, 1С, CRM, ERP, собственная база или несколько систем сразу.
4. Как часто меняются данные? Раз в неделю, каждую минуту или индивидуально для каждого пользователя.
5. Какие готовые компоненты обязательны? Один отраслевой React-редактор иногда весит в решении больше, чем десяток общих критериев.
6. Где будет работать приложение? Статический CDN, один VPS, Kubernetes, бессерверная платформа или инфраструктура заказчика.
7. Кто будет поддерживать проект через два года? Знакомый команде стек часто надёжнее модного, но чужого инструмента.

Для B2B-продуктов этот разбор начинается с ролей, юрлиц, договоров и плательщиков: подробнее — в статье про модель сущностей B2B-кабинета.

Ответы формируют не только выбор фреймворка, но и режим рендеринга внутри него. Две системы на Nuxt могут отличаться сильнее, чем правильно спроектированные Nuxt- и Next.js-приложения.

Частые ошибки при сравнении

Сравнивать пустые стартовые проекты

Пустая страница ничего не говорит о каталоге с 600 000 товаров, десятке API и сторонней аналитике. Производительность определяют архитектура данных, изображения, шрифты, клиентские библиотеки, кэш и качество реализации.

Выбирать только по SEO

Все четыре фреймворка умеют серверный или статический HTML. Для SEO важнее корректные URL, метаданные, canonical, sitemap, микроразметка, скорость ответа и отсутствие контента, который появляется только после загрузки браузерного JavaScript.

Считать фреймворк с серверным слоем заменой архитектуре бэкенда

Route Handler или server action удобны, но не отменяют границы доменов, очереди, идемпотентность и источники истины. В наших e-commerce проектах за витриной остаются Symfony, ASP.NET, Directus, 1С, ERP и CRM. Фронтенд-фреймворк связывает пользовательский опыт, но не должен незаметно присвоить себе всю бизнес-логику.

Игнорировать эксплуатацию

Приложение на одном сервере и кластер из нескольких экземпляров имеют разные требования к кэшу, сессиям и инвалидированию. Статическая сборка снижает риски серверной эксплуатации, но может сделать публикацию слишком долгой. Бессерверная архитектура упрощает масштабирование, но меняет работу с соединениями, локальным диском и фоновыми задачами.

Выбирать «на будущее» без конкретного будущего

Фраза «потом у нас будет сложный кабинет» недостаточна. Нужны хотя бы сценарии: роли, персональные цены, документы, совместная работа, обмен данными в реальном времени. Иначе команда платит за сложность Next.js или Nuxt сейчас, а обещанное приложение так и не появляется.

Итоговая рекомендация

Если сократить выбор до одного правила, оно будет таким:

• Nuxt — когда строим долгоживущий публичный продукт с большим каталогом, Vue-интерфейсом и интеграциями;
• Next.js — когда строим сложное React-приложение, где серверные компоненты, BFF и богатая экосистема оправдывают дополнительную архитектурную сложность;
• Astro — когда основа продукта — контент, а интерактивность можно честно выделить в отдельные острова;
• SvelteKit — когда нужен полноценный интерактивный продукт с лаконичным UI-кодом, и команда готова работать с более компактной экосистемой.

Фреймворк не делает продукт быстрым, масштабируемым или удобным автоматически. Он лишь задаёт направление, в котором проще двигаться. Хороший выбор совпадает с природой проекта; плохой заставляет команду всё время компенсировать архитектурный дефолт инструмента.

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