Новый фреймворк vinext сократил размер клиентских бандлов на 56% в тестовом приложении.

Cloudflare показала необычный эксперимент на стыке ИИ и разработки и сразу попала в центр внимания фронтенд-сообщества. Инженер компании вместе с ИИ-моделью за несколько дней собрал vinext, совместимую альтернативу Next.js на базе Vite, которую можно деплоить в Cloudflare Workers одной командой. Авторы проекта заявляют более быструю сборку и заметно меньшие клиентские бандлы по сравнению с Next.js в тестовом сценарии.
Появление vinext Cloudflare объясняет старой проблемой Next.js в serverless-средах. Сам фреймворк удобен для разработки, но при запуске на разных платформах инженерам часто приходится подгонять результаты сборки под конкретную инфраструктуру. Для такой задачи уже используют OpenNext, и Cloudflare прямо признает ценность проекта, но называет подход хрупким. Причина простая: OpenNext вынужден разбирать и переупаковывать внутренний build output Next.js после изменений, а локальная разработка все равно остается привязанной к Node.js. Из-за такой связки разработчикам сложнее тестировать сервисы Cloudflare и платформенные API еще на этапе dev-сборки.
Вместо очередного адаптера команда решила повторить API-поверхность Next.js поверх Vite. vinext не использует внутреннюю сборку Next.js и не оборачивает Turbopack. Проект заново реализует ключевые механики через Vite-плагин, включая маршрутизацию, SSR, React Server Components, server actions, кэширование и middleware. По описанию Cloudflare, миграция выглядит довольно мягкой: разработчику достаточно поставить пакет и заменить next на vinext в скриптах, а папки app и pages, как и next.config.js, продолжают работать без переписывания.
Самая заметная часть анонса связана с производительностью сборки. В тестовом приложении с 33 маршрутами vinext на Vite 7 и Rollup собрал проект быстрее, чем Next.js 16.1.6 с Turbopack. Версия на Vite 8 и Rolldown показала еще больший отрыв. Cloudflare также сообщила о сокращении размера клиентского gzipped-бандла примерно на 56-57% в том же тесте. Команда отдельно уточняет границы сравнения: речь идет о времени компиляции и сборки, а не о производительности продакшн-сервинга, и результаты получены на одном приложении.
Пока vinext ориентирован прежде всего на Cloudflare Workers. Для деплоя компания готовит команду vinext deploy, которая собирает приложение, создает конфигурацию Worker и отправляет проект в продакшн. Проект поддерживает App Router и Pages Router, клиентскую гидратацию и навигацию. Для кэширования Cloudflare предлагает обработчик на базе KV с ISR «из коробки», а кэш-слой сделала сменным, чтобы при желании подключать другие хранилища, включая R2. Такой подход особенно интересен командам, которым нужны Durable Objects, AI bindings и другие сервисы Cloudflare уже на этапе локальной разработки.
Cloudflare не пытается выдать vinext за готовую замену Next.js для всех сценариев. Компания прямо пишет, что проект экспериментальный, существует меньше недели и пока не прошел проверку крупными боевыми нагрузками. При этом команда показывает серьезную подготовку по тестированию: более 1700 тестов на Vitest, сотни E2E-проверок на Playwright, перенос тестов из экосистемы Next.js и OpenNext, а совместимость с API Next.js 16 оценивается в 94%. В качестве раннего примера Cloudflare называет сайт CIO.gov, где vinext уже работает в продакшне и, по словам компании, дает выигрыш по сборке и размеру бандла.
Отдельно Cloudflare предложила способ ускорить запуск больших сайтов без полной предварительной генерации всех страниц. Сейчас vinext умеет ISR после первого запроса, но пока не поддерживает классический статический pre-render на этапе сборки. Вместо полного пререндеринга команда тестирует режим Traffic-aware Pre-Rendering. Во время деплоя система анализирует данные о трафике Cloudflare и заранее рендерит только страницы, которые дают основной поток посещений. Для каталогов с десятками и сотнями тысяч URL такой подход может резко сократить время сборки, потому что «горячие» страницы готовятся заранее, а остальная масса уходит в SSR с последующим кэшированием через ISR.
Самый громкий тезис в анонсе касается процесса разработки. Cloudflare утверждает, что почти весь код vinext сгенерировала ИИ-модель под контролем одного инженера, а затраты на токены составили около 1100 долларов. По словам автора проекта, первый коммит появился 13 февраля, а к концу дня уже заработали базовый SSR, middleware, server actions и streaming для обоих роутеров. Дальше команда добивала совместимость, тесты и сложные кейсы.
При этом Cloudflare не описывает работу как «волшебную кнопку». Инженер задавал архитектуру, расставлял приоритеты, останавливал неудачные решения и держал процесс в рамках жестких quality gates. Цикл выглядел знакомо любому разработчику: постановка задачи, генерация кода и тестов, прогон проверок, исправления и повторение. Часть ревью pull request выполняли агентные инструменты, но финальные решения оставались за человеком.
На практике vinext пока выглядит не как «убийца Next.js», а как сильный эксперимент для Cloudflare Workers и одновременно демонстрация нового подхода к инженерной работе. Один специалист с ИИ, зрелой платформой и хорошим набором тестов смог быстро собрать проект, который раньше почти наверняка потребовал бы отдельную команду. Для рынка фронтенда сигнал получился громким, даже если окончательные выводы о надежности vinext появятся только после длительной эксплуатации.