Проблема
Это не Vue vs React
Сразу по-честному: я не выбираю Nuxt потому, что мне не нравится React. И не потому что Next.js «дырявый». Причина прозаичнее.
У меня сейчас около 10 клиентских проектов в разной стадии жизни. Одни в активной разработке, другие давно сданы и просто работают — бюджет закрыт, контекст забыт. Когда в такой ситуации выходит security advisory с пометкой critical, это уже не одна команда pnpm update. Это задача, которая размножается: найти, какие проекты затронуты, проверить версии, обновить, проверить что не сломалось, согласовать деплой с клиентом.
На одном проекте — нормально. На десяти — уже ощутимо.
Вот из-за этого я всё чаще начинаю новые клиентские проекты на Nuxt.
Что такое security-maintenance cost
Это не стандартный термин, но я его использую для себя. Имею в виду не «насколько фреймворк безопасен в абстрактном смысле», а сколько времени реально стоит держать его безопасным на нескольких живых проектах.
Зависит от нескольких вещей: как часто выходят патчи к уязвимостям, насколько они срочные, ломают ли они поведение проекта, можно ли обновить минорную версию без миграции, сколько параллельных проектов под раздачу, есть ли у клиента бюджет на поддержку.
Для меня это превращается в конкретный вопрос: смогу ли я через год после релиза быстро и без паники обновить проект, который уже давно не в активной разработке?
Nuxt vs Next.js
Почему Next.js стал ощущаться тяжелее
Next.js — это уже давно не просто фреймворк с SSR. Это серверная платформа: App Router, React Server Components, middleware, Server Actions, кэш и ревалидация, image optimization, edge и node runtimes. Каждый из этих слоёв — своя зона ответственности с точки зрения безопасности. И чем больше слоёв, тем чаще патчи касаются production-поведения, а не только зависимостей.
В конце 2025 года React зафиксировал критическую уязвимость в React Server Components (CVE-2025-55182, CVSS 10.0) — unauthenticated RCE. Среди затронутых фреймворков указан Next.js, обновляться рекомендовали немедленно. После этого выяснилось, что первый патч был неполным: вышли дополнительные advisory по DoS и source-code exposure, снова с рекомендацией обновляться.
Параллельно шли проблемы у самого Next.js: authorization bypass в middleware с CVSS 9.1 и middleware/proxy bypass через segment-prefetch routes — уже в мае 2026.
У меня нет претензии к тому, что в популярных проектах находят уязвимости — это нормально для любого живого кода. Проблема в другом: когда фреймворк обрастает сложной моделью кэша, маршрутизации и server/client границ, security-патчи начинают касаться не абстрактных corner cases, а того, как конкретно работает авторизация или что отдаётся в prefetch. Такие патчи уже не пропустишь.
Почему это особенно ощущается в клиентских проектах
В advisory написано «upgrade immediately». В реальной жизни за этим стоит:
- Найти, какие из проектов затронуты и на каких версиях
- Проверить lockfile, понять что именно обновлять
- Обновить зависимости
- Разобраться с breaking changes или изменениями поведения
- Прогнать тесты — если они есть
- Вручную проверить auth, формы, SSR, middleware, кэш
- Договориться с клиентом про окно деплоя
- После деплоя убедиться, что ничего не отвалилось
Если это мой активный продукт — я могу заложить на это время. Если это клиентский проект, который полгода назад сдан и закрыт, всё сложнее. Контекст надо восстанавливать. Клиент не всегда понимает, зачем платить за «технические обновления». А срочность никуда не девается.
В security advisory обычно написано «upgrade immediately». В реальной жизни за этим стоит вечер с чужим проектом, который ты не открывал полгода.
Почему Nuxt в моих задачах выглядит спокойнее
Сразу оговорюсь: не потому что Nuxt «безопасный по умолчанию». Просто его модель мне легче держать в голове.
В Nuxt видно, где что. Есть pages, server routes, middleware, Nitro. Это полноценный full-stack, но с более явными границами. Я быстрее понимаю, какую часть надо смотреть после обновления. Меньше RSC-специфичной логики. Меньше вопросов в духе «это выполняется на клиенте или на сервере, и влияет ли это на кэш».
Для клиентских проектов это важно ещё и потому, что их потом читают другие разработчики. Объяснить «здесь server route, вот middleware, вот Nitro config» — проще, чем объяснять разницу между RSC, Server Actions, client component boundary и тем, почему этот конкретный запрос идёт через edge, а не node.
Когда операционная сложность меньше, патчи обычно затрагивают более понятные слои. Это не гарантия, но в моей практике — заметная разница.
Но и Nuxt не стерилен
Это важно сказать прямо, иначе получится рекламный пост.
В security advisories nuxt/nuxt есть реальные истории: cache poisoning DoS, source-code exposure через dev-server, XSS в navigateTo, path traversal в Nuxt DevTools. В апреле 2026 у Nitro появились moderate advisories — open redirect и proxy scope bypass через routeRules.
Если в проекте есть SSR, server routes, CDN, user-generated content, preview-режим или нестандартные routeRules — поверхность атаки есть. Разница для меня не в том, что Nuxt «безопасный», а в том, что его операционная сложность в типичных задачах ниже. Обновления реже задевают что-то неожиданное.
Когда что выбирать
Когда я всё равно выберу Next.js
Если команда пишет на React — не имеет смысла тащить Vue без конкретной причины. Если проект сильно завязан на React-экосистему: shadcn/ui, Radix, TanStack — Next.js органичнее. Vercel-first инфраструктура тоже меняет расчёт.
Главное: если у проекта есть нормальный процесс обновлений — Renovate или Dependabot, staging, тесты, конкретный человек, который отвечает за поддержку — Next.js вполне нормальный выбор. Тогда advisory превращается в плановую задачу, а не в экстренный вечер.
Моя претензия не к Next.js как инструменту. Претензия к ситуации, когда этот инструмент ставят в проекты, которые потом никто системно не сопровождает.
Мой текущий выбор по типу проекта
Личный сайт или блог — Astro или Nuxt: меньше runtime, меньше будущих патчей. Небольшой клиентский сайт — Nuxt или Astro: проще держать в голове и обновлять. Кабинет или SaaS MVP — Nuxt: хороший баланс full-stack и DX. React-heavy продукт с командой — Next.js: стек и экосистема важнее. Vercel-first проект — Next.js: меньше трения с платформой. Проект без бюджета на поддержку — минимальный runtime: меньше срочных патчей в будущем.
Не страх, а стоимость владения
Уязвимости будут везде: в Next.js, в Nuxt, в Nitro, в том фреймворке, который выйдет через два года. Это не аргумент против любого инструмента — это просто данность.
Я не выбираю Nuxt из страха перед CVE. Я выбираю его чаще потому, что для большинства моих задач он даёт более предсказуемую стоимость владения. Чем понятнее серверная модель и чем меньше слоёв между запросом и ответом, тем проще обслуживать проект через год после релиза.
Для меня лучший фреймворк — не тот, который выглядит мощнее в день старта, а тот, который я смогу спокойно обновить через год.