Nuxt, Next.js, Rust: почему мы меняем стек и когда не стоит

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

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

2023–2024: почти всё на Nuxt 3

Когда студия начала брать крупные проекты, мы выбрали связку Django + Nuxt 3. На ней сделаны Mening Yurtim (MY5), Legal Alliance, PlanBaby, UZBCONTENT, Japanese Garden, IBN Express, лендинги телеканалов.

Почему Vue и Nuxt? Шаблоны во Vue читаются почти как HTML, и новому человеку в команде проще войти. SSR работает из коробки, а для телеканалов и юридических фирм поисковый трафик важен. Django давал готовую админку, которую клиенты осваивали за день.

Я до сих пор считаю, что это было правильное решение для того времени. MY5 мы поддерживаем с 2023 года, там больше 140 коммитов, и сайт спокойно работает на том же стеке.

Хотя гладко было не всё. Nuxt 3 вышел в стабильной версии в конце 2022 года, и в первые месяцы часть модулей, к которым мы привыкли, ещё не была под него переписана. Что-то приходилось делать руками, что-то ждать. Это была цена раннего входа, и я считаю, что мы её заплатили осознанно.

Цифры посчитаны по проектам, которые есть на сайте. Боты и мобильные приложения сюда не входят.

2025: почему мы перешли на Next.js

Переход случился не за один день. Причин было три, и ни одна из них не про «Next.js лучше Nuxt».

Люди. В Ташкенте React-разработчиков заметно больше, чем Vue-разработчиков. Это видно по любому поиску на hh.uz или в Telegram-каналах с вакансиями.

Библиотеки. Пакеты для многоязычности (next-intl), для форм, для аналитики выходят под React раньше. На Enlawyer нам нужны были три языка, structured data, sitemap на каждую локаль, и под React всё это было готовым.

ИИ-ассистенты. Звучит странно, но это реальный фактор. Ассистенты пишут код для React и Next.js заметно увереннее, чем для Nuxt, потому что обучались на большем количестве примеров. Для маленькой студии это часы в неделю.

Дальше на Next.js сделаны Enlawyer, Excellent Print, Mezon Ta'lim и Xina Soliha. Последние два уже на Next.js 16.

Бесплатным переход не был. App Router и серверные компоненты в React устроены иначе, чем то, к чему мы привыкли в Nuxt, и первые проекты на Next.js шли медленнее обычного. Мы несколько раз переделывали одно и то же, пока не поняли, где граница между серверным и клиентским кодом. Плюс теперь в студии два фронтенд-стека одновременно: старые сайты на Vue никто не отменял, и их тоже нужно уметь поддерживать.

Damka: три версии за два года

Тут я ошибался больше всего, и это нормально, потому что Damka.uz — наш собственный продукт, платформа для игры в русские шашки.

Первая версия в 2024 году была на Django и Nuxt: игра, комнаты, всё через обычные запросы. Работало, но для живой игры между двумя людьми этого мало.

Вторая версия перешла на Django Channels и WebSockets, Nuxt 4 на фронте. Появились ИИ-соперник на алгоритме negamax с альфа-бета отсечением, рейтинг ELO, подбор соперника, режим зрителя. Здесь упёрлись в Python: поиск ходов — это чистая нагрузка на процессор, и чем глубже бот считает, тем дольше ждёт игрок.

Третья версия — игровой движок на Rust (actix-web, WebSocket) с оценкой позиции нейросетью. Фронт на React, админка на Next.js, плюс Telegram-бот, в котором можно играть прямо в групповом чате и проводить турниры по правилам IDF.

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

Shajara: Fastify вместо Django

Shajara — наш стартап для семейного древа, где несколько родственников одновременно редактируют одно дерево. Это real-time, и на Django Channels мы бы его сделали, но выбрали Fastify 5, Drizzle ORM и PostgreSQL, на фронте React 19 и Vite, синхронизация через Socket.IO.

Главная причина: один язык. Типы из TypeScript идут от базы до компонента, и когда меняется структура узла дерева, ломается сборка, а не продакшен. Само дерево рисуется через d3, вход через Google, интерфейс на узбекском, русском и английском. Для продукта, где данные сложные и вложенные, это сэкономило больше времени, чем любая скорость фреймворка.

Для клиентских проектов я бы так пока не делал. Django с его админкой остаётся нашим основным бэкендом. Fastify — это инструмент под конкретную задачу.

Правило скучных технологий

Ниже наш внутренний принцип. Я сформулировал его после второй переписки Damka.

На практике это значит: Rust живёт только в Damka. Fastify только в Shajara. Клиент, который заказывает корпоративный сайт, получает Django и Next.js, проверенные на десятке проектов.

Что не менялось ни разу

Если посмотреть на всё, что выше, легко решить, что мы меняем технологии каждый год. Но большая часть стека за четыре года не поменялась вообще. PostgreSQL во всех проектах, где есть база. Redis для кэша и очередей. Celery для фоновых задач: рассылки, отчёты, обработка картинок. Docker и GitLab CI для деплоя. nginx перед всем этим.

Боты тоже живут на одном и том же aiogram. Старые проекты на aiogram 2 мы переводим на третью версию, только когда всё равно открываем код по другой причине. Переписывать работающего бота ради новой версии библиотеки не имеет смысла, если он принимает заявки и никто не жалуется.

Именно эта неизменная часть позволяет экспериментировать с остальным. Когда база, деплой и мониторинг одинаковые везде, смена фронтенд-фреймворка — это смена одного слоя, а не всего проекта.

Перед тем как менять стек

Если вы руководите командой или выбираете подрядчика, вот вопросы, которые я задаю себе каждый раз. Если на большинство ответ «нет», я оставляю стек как есть.

Если коротко, что я сделал бы иначе: отделил бы движок Damka от веба с первой версии и не тратил бы время на вторую. А переход с Nuxt на Next.js повторил бы точно так же, постепенно и без переписывания старого.