Cloudflare reimplementou o Next.js em uma semana com AI: conheça o vinext

Ontem (24/02) a Cloudflare publicou algo que chamou atenção de muita gente: um engenheiro reimplementou a superfície de API do Next.js do zero, em cima do Vite, em uma semana. O resultado é o vinext (pronuncia "vee-next"), um drop-in replacement pro Next.js que já tem apps reais rodando sobre ele.

O custo total? Cerca de $1.100 em tokens de AI.

O problema que motivou tudo

Next.js é o framework React mais popular do mercado. Milhões de devs usam. Mas ele tem um problema estrutural quando você quer fazer deploy fora da Vercel.

O tooling do Next.js é todo proprietário. O Turbopack gera um output específico, e se você quer rodar isso na Cloudflare, Netlify ou AWS Lambda, precisa pegar esse output e transformar em algo que a plataforma consiga executar.

Pra resolver isso existe o OpenNext, e vários providers (incluindo a própria Cloudflare) investiram bastante nele. Funciona, mas é frágil. Cada mudança interna do Next.js pode exigir ajustes no OpenNext, porque ele depende de engenharia reversa do build output. É um alvo móvel.

O Next.js tá trabalhando numa API de adapters, mas mesmo com adapters você ainda depende do Turbopack. E no desenvolvimento local, o next dev roda exclusivamente em Node.js. Se sua app usa APIs específicas da plataforma (Durable Objects, KV, AI bindings), não dá pra testar em dev sem gambiarras.

O que é o vinext

Em vez de adaptar o output do Next.js, a Cloudflare reimplementou a superfície de API do Next.js direto no Vite. Não é wrapper. Não é adapter. É uma implementação alternativa: roteamento, server rendering, React Server Components, server actions, caching, middleware. Tudo construído como plugin do Vite.

Na prática, a migração é trocar next por vinext nos seus scripts:

npm install vinext

vinext dev    # Dev server com HMR
vinext build  # Build de produção
vinext deploy # Build + deploy pra Cloudflare Workers

Seus diretórios app/, pages/ e next.config.js continuam funcionando como antes.

Os números

Os benchmarks iniciais foram feitos com um app de 33 rotas usando App Router, comparando Next.js 16.1.6 (Turbopack) contra o vinext. São benchmarks controlados de compilação e bundling, não testes de produção.

Tempo de build (produção):

• Next.js 16.1.6 (Turbopack): 7.38s (baseline)
• vinext (Vite 7 / Rollup): 4.64s (1.6x mais rápido)
• vinext (Vite 8 / Rolldown): 1.67s (4.4x mais rápido)

Tamanho do bundle client (gzipped):

• Next.js 16.1.6: 168.9 KB (baseline)
• vinext (Rollup): 74.0 KB (56% menor)
• vinext (Rolldown): 72.9 KB (57% menor)

O Rolldown é o bundler baseado em Rust que vem no Vite 8, e é onde os ganhos reais aparecem. Os benchmarks são públicos e rodam no GitHub CI a cada merge. A metodologia completa tá em benchmarks.vinext.workers.dev.

A própria Cloudflare pede pra tratar esses números como direcionais, não definitivos. O teste usa um app de 33 rotas, e os resultados vão evoluir conforme os três projetos (Next.js, Vite e vinext) continuem sendo desenvolvidos.

Traffic-aware Pre-Rendering (TPR)

Uma das features mais interessantes é o TPR. O conceito é simples e esperto.

No Next.js, se você tem 10.000 páginas de produto e usa generateStaticParams(), o build renderiza todas elas. Mesmo que 99% nunca receba uma visita. O tempo de build escala linearmente com a quantidade de páginas. É por isso que sites grandes de Next.js acabam com builds de 30 minutos.

O vinext faz diferente: como a Cloudflare está no caminho de todo request da zona (é o reverse proxy do seu site), ela tem dados reais de tráfego. Não é analytics comum. No deploy, o vinext consulta esses dados e pré-renderiza só as páginas que importam.

vinext deploy --experimental-tpr

  Building...
  Build complete (4.2s)

  TPR: Analyzing traffic for my-store.com (last 24h)
  TPR: 12,847 unique paths — 184 pages cover 90% of traffic
  TPR: Pre-rendering 184 pages...
  TPR: Pre-rendered 184 pages in 8.3s → KV cache

  Deploying to Cloudflare Workers...

Pra um site com 100.000 páginas, a lei de potência faz com que 90% do tráfego vá pra 50 a 200 páginas. Essas são pré-renderizadas em segundos. O resto cai em SSR on-demand e é cacheado via ISR após o primeiro request. Sem generateStaticParams(), sem acoplar o build ao banco de produção.

Como foi construído

A maior parte do código do vinext foi gerada com AI, sob direção humana de Steve Faulkner (engineering manager da Cloudflare).

O primeiro commit foi no dia 13 de fevereiro. No mesmo dia à noite, Pages Router e App Router já tinham SSR básico funcionando, com middleware, server actions e streaming. No segundo dia, o App Router Playground renderizava 10 de 11 rotas. No terceiro dia, vinext deploy já mandava apps pra Cloudflare Workers com hydration completo no client.

O projeto tem mais de 1.700 testes Vitest e 380 testes E2E com Playwright, incluindo testes portados direto do repositório do Next.js. A cobertura da API do Next.js 16 tá em 94%.

Por que funcionou? Porque o Next.js é extremamente bem documentado (a API tá toda no training data dos modelos), tem uma suite de testes enorme pra validar contra, e o Vite é uma base sólida que já resolve os problemas difíceis de tooling frontend. Além disso, os modelos atuais conseguem manter coerência em codebases desse tamanho, algo que não era possível há poucos meses.

O que ainda não funciona

O vinext é experimental. Tem menos de uma semana de vida. Alguns pontos:

• Pré-renderização estática em build time ainda não funciona (tá no roadmap)
• Se seu site é 100% HTML estático, o benefício hoje é limitado
• O target principal de deploy é Cloudflare Workers (mas 95% do código é puro Vite)
• Já tem um POC rodando na Vercel que levou 30 minutos pra adaptar

O repositório é aberto e honesto sobre o que não é suportado e o que são limitações conhecidas.

O que isso significa na prática

Pra quem trabalha com Next.js, o vinext é relevante por alguns motivos:

1. Se você faz deploy fora da Vercel, a vida acaba de ficar mais simples. Nada de OpenNext, nada de adaptar output.
2. Build mais rápido significa CI mais rápido, feedback loop menor, menos café esperando deploy.
3. Bundles menores significam apps mais rápidas pro usuário final.
4. Dev local com runtime real significa testar APIs da plataforma sem gambiarras.

Mas o ponto maior é outro. Um engenheiro reimplementou a superfície de API de um framework usado por milhões de devs, em uma semana, por $1.100. A complexidade de fazer isso não mudou. O custo de executar mudou radicalmente.

Referência

Post original da Cloudflare com todos os detalhes técnicos, demos ao vivo e benchmarks: How we rebuilt Next.js with AI in one week

Repositório: github.com/cloudflare/vinext