Cloudflare выложила vinext — экспериментальный проект, который повторяет API Next.js, но собран вокруг Vite и ориентирован на Cloudflare Workers. Интереснее всего не скорость сборки, а то, как продукт создавали: большую часть кода написали ИИ-сессии, а качество пытались удержать тестами и строгими проверками.
Cloudflare выпустила vinext — экспериментальную переработку подхода Next.js, но на другом «движке»: вместо Turbopack проект опирается на Vite. История получилась показательной не только из-за цифр в бенчмарках: разработку вели в ускоренном режиме с активной помощью ИИ, а дальше началась ожидаемая дискуссия о поддерживаемости такого кода.
Что вообще произошло
vinext позиционируют как drop-in замену для приложений на Next.js, с упором на запуск в Cloudflare Workers. По описанию проекта, над ним работал один инженер примерно неделю, а на API-токены для ИИ ушло $1 100.
Важно: авторы честно маркируют релиз как эксперимент и предупреждают, что решение не проверено нагрузками «боевого» масштаба.
Почему это может заинтересовать разработчиков
Next.js часто выбирают за удобный каркас вокруг React: маршрутизацию, рендеринг на сервере, работу с данными и кешированием. Но в больших проектах быстро всплывает другая сторона: сборка и деплой становятся заметной частью расходов времени и нервов.
Cloudflare пытается показать альтернативный путь: сохранить привычный интерфейс Next.js, но перенести реализацию в формат Vite-плагина и сделать средой выполнения Workers.
Цифры: быстрее сборка, меньше бандл — но это не «приговор» Next.js
В одном тестовом приложении (33 маршрута) Cloudflare приводит такие результаты:
- production build: 1,67 секунды против 7,38 секунды у Next.js 16 с Turbopack (примерно в 4,4 раза быстрее);
- клиентский бандл: 72,9 KB gzip против 168,9 KB gzip (снижение примерно на 57%).
При этом сами авторы подчеркивают: замеры «направляющие», а не окончательные — это один сценарий, а не статистика по реальным продуктам.
Как vinext устроен: совместимость с Next.js и фокус на Workers
По описанию Cloudflare, vinext закрывает значительную часть API-поверхности Next.js: маршрутизацию, серверный рендеринг, React Server Components, server actions, кеширование и middleware. Проект рассчитан на платформы, которые поддерживают Vite Environment API, но основной целевой сценарий — Cloudflare Workers.
Отдельно упоминается тезис, что около 95% кода — это платформенно-независимая часть, завязанная на Vite.
Качество: ставка на тесты и «ворота» проверок
Если большую часть кода пишет ИИ, «страховка» обычно одна: проверки. В vinext заявлены:
- более 1 700 тестов на Vitest;
- около 380 E2E-тестов на Playwright, перенесённых из тестового набора Next.js;
- проверки TypeScript и линтинг как обязательные этапы.
Также описан рабочий процесс: ИИ генерировал изменения и тесты, прогонялся набор проверок, и только при успешном прохождении изменения попадали в кодовую базу. Если тесты падали — ИИ получал ошибки и итеративно исправлял.
Ограничение, которое сразу влияет на архитектуру
Ключевой функциональный пробел на старте — нет статического пререндеринга на этапе сборки. То есть vinext пока не делает привычный для Next.js сценарий, когда страницы заранее вычисляются во время build (например, через generateStaticParams()).
Вместо этого упор сделан на ISR-подход: страница строится по запросу, кешируется и затем может перевалидироваться.
Идея «пререндерить только то, что реально читают»
Вокруг этого ограничения Cloudflare предлагает альтернативу: экспериментальный механизм Traffic-aware Pre-Rendering (TPR). Идея простая: при деплое смотреть аналитику по посещаемости и заранее «готовить» только те страницы, куда действительно ходят.
Пример сценария, который приводится в описании: каталог на 100 000 карточек, где почти весь трафик приходится на 50–200 страниц. Тогда именно они пререндерятся, а остальные останутся в режиме отложенного серверного рендеринга.
Ограничение этого подхода тоже очевидно: он завязан на наличие данных по трафику, то есть лучше подходит для сайтов, которые уже живут внутри инфраструктуры Cloudflare и накопили статистику.
Почему вокруг vinext спорят: скорость против поддерживаемости
vinext стал триггером для важного разговора: если код действительно создаётся «сверхбыстро» при помощи ИИ, кто и как будет поддерживать его через полгода? В обсуждениях звучит скепсис в стиле «код никто по-настоящему не прочитал» и опасения, что проект держится на тестах и заимствованной контрактной базе (в том числе тестах, которые уже были у Next.js).
На практике это означает следующее: даже если технология впечатляет в демо, для продакшена нужен привычный набор ответов — кто владелец архитектуры, как устроены релизы, как ловят регрессии, как принимают решения без «магии ИИ».
Кому стоит присмотреться, а кому — подождать
- Стоит поэкспериментировать, если вы строите проект под Workers и хотите проверить, можно ли получить привычные паттерны Next.js с другим пайплайном сборки.
- Лучше подождать, если вам критичны статические страницы «из коробки» и предсказуемая зрелость экосистемы.
- Нужно закладывать риски, если в компании важны понятные правила сопровождения: проект молодой и прямо объявлен «не закалённым продакшеном».
vinext выглядит как демонстрация новой реальности: ИИ ускоряет производство кода, но не отменяет требования к ответственности, тестовой дисциплине и ясной архитектуре. Скорость стала проще купить — доверие всё ещё нужно заслужить.
