- A antiga estrutura dupla esbuild + Rollup foi unificada em um único bundler Rolldown baseado em Rust, alcançando desempenho de build até 10 a 30 vezes mais rápido
- Um novo registro de plugins foi lançado, permitindo pesquisar e gerenciar plugins do Vite, Rolldown e Rollup
- Foram adicionados recursos de conveniência para desenvolvimento, como Vite Devtools, resolução de caminhos do TypeScript, Wasm SSR e encaminhamento de console
- Este lançamento representa a maior mudança estrutural do ecossistema Vite até agora e serve de base para a evolução futura de uma toolchain integrada
Vite 8 baseado em Rolldown
- O Vite 8 unifica a antiga estrutura de dois bundlers — esbuild (para desenvolvimento) e Rollup (para produção) — em um único bundler, o Rolldown
- O Rolldown é um bundler de alto desempenho escrito em Rust e oferece suporte à mesma API de plugins do Rollup
- A maior parte dos plugins existentes do Vite funciona sem modificações adicionais
- Em desempenho, ele é de 10 a 30 vezes mais rápido que o Rollup e oferece recursos avançados como cache por módulo, divisão flexível de chunks e Module Federation
Processo de adoção do Rolldown
- No início, uma prévia técnica foi disponibilizada por meio do pacote
rolldown-vite para coletar feedback da comunidade
- Foram testadas diversas bases de código reais para resolver problemas de compatibilidade
- Foi criada uma estrutura dedicada de testes em CI voltada para os principais plugins e frameworks
- Em dezembro de 2025, o beta do Vite 8 foi lançado com o Rolldown totalmente integrado
- Durante o período beta, o Rolldown evoluiu para a fase de Release Candidate e foi estabilizado
Casos reais de melhoria de desempenho
- Diversas empresas relataram redução no tempo de build
- Linear: 46 s → 6 s
- Ramp: redução de 57%
- Mercedes-Benz.io: redução de até 38%
- Beehiiv: redução de 64%
- Quanto maior o projeto, mais evidente é o ganho, e novas melhorias contínuas no Rolldown já foram anunciadas
Toolchain integrada e stack tecnológica
- O Vite 8 evolui para uma toolchain end-to-end na qual Vite (ferramenta de build), Rolldown (bundler) e Oxc (compilador) trabalham em estreita colaboração
- Garante consistência em todo o processo de parsing, transformação e otimização
- Permite otimização de tree shaking com uso da análise semântica do Oxc
- Cria uma estrutura capaz de adotar rapidamente novas especificações de JS
Recursos adicionais
- Vite Devtools: permite analisar visualmente o estado do projeto no servidor de desenvolvimento
- Suporte nativo à resolução automática de caminhos (alias) do TypeScript e ao emitDecoratorMetadata
- Wasm SSR: suporte a importações
.wasm?init em ambientes de server-side rendering
- Encaminhamento do console do navegador: envia erros do navegador ao terminal para melhorar a eficiência da depuração
- @vitejs/plugin-react v6: remoção do Babel, adoção de React Refresh baseado em Oxc e redução do tamanho da instalação
Direção futura do desenvolvimento
- Full Bundle Mode (experimental): realiza bundling também durante o desenvolvimento, alcançando inicialização do servidor 3 vezes mais rápida, reload 40% mais rápido e 10 vezes menos requisições de rede
- Transmissão de AST bruto e transformações Native MagicString reduzem a lacuna de desempenho entre Rust e JS
- Está em andamento uma colaboração no ecossistema para estabilizar a Environment API
Mudança no tamanho da instalação
- O Vite 8 é cerca de 15 MB maior que o Vite 7
- lightningcss (cerca de 10 MB): fornece compressão de CSS por padrão
- Binário do Rolldown (cerca de 5 MB): aumento de tamanho em troca de otimização de velocidade
- A otimização de tamanho continuará nas próximas versões
Guia de migração
- A maioria dos projetos pode fazer upgrade sem alterar a configuração
- As configurações existentes de
esbuild e rollupOptions são convertidas automaticamente
- Para projetos grandes, é recomendada uma migração em duas etapas
- Migrar do Vite 7 para
rolldown-vite e depois fazer upgrade para o Vite 8
- Os procedimentos detalhados podem ser consultados no Migration Guide e no Changelog oficiais
Agradecimento ao Rollup e ao esbuild
- O Rollup forneceu a base do ecossistema de plugins do Vite, e o Rolldown herda essa API
- O esbuild foi uma tecnologia central para viabilizar uma experiência de desenvolvimento rápida e impulsionou a evolução do tooling baseado em Rust e Go
- As contribuições dos dois projetos estão profundamente incorporadas ao DNA do Vite
Comunidade e colaboração
- O desenvolvimento do Vite 8 foi concluído por meio da colaboração entre sapphi-red e a equipe do Vite, a equipe do Rolldown e numerosos contribuidores da comunidade
- VoidZero, Bolt e NuxtLabs participaram como principais parceiros
5 comentários
Opiniões do Hacker News
Isso faz pensar novamente em quantos recursos computacionais a indústria desperdiçou com ferramentas ineficientes usadas sem questionamento, sob a ideia de que “builds naturalmente demoram”
Nós planejávamos cronogramas em torno desses builds lentos, transformávamos pausas em piada e até construíamos camadas de cache
Meus aplausos aos mantenedores do Vite
A maior parte do software em produção é dezenas de vezes mais lenta do que precisaria ser
O fato de apps em Electron consumirem vários GB de RAM e ainda travarem mais do que softwares de 40 anos atrás é prova disso
Há 14 anos, percebi o tempo desperdiçado esperando builds e senti que isso era especialmente grave no ecossistema Java
Em um projeto Ruby antigo, os testes de integração levavam 10 minutos por recriarem o DB toda vez
Kotlin/Spring Boot também compila devagar, e o compilador de Rust também não é exatamente rápido
Mas testes estão sob nosso controle. Testes unitários deveriam terminar em milissegundos, e testes de integração podem melhorar muito com paralelização e randomização de dados
Eu rodo centenas de testes de integração em Spring, com Redis, DB e Elasticsearch, em menos de 40 segundos no meu MacBook Pro
Depois que você monta isso uma vez, surge um loop de feedback rápido e a alegria de desenvolver volta
A parte em que contribuí para o Vite 8 foi o suporte a Wasm SSR
Estendi imports
.wasm?initpara funcionarem também em ambiente SSRO processo foi lento, mas fiquei impressionado com o quanto o time ajudou nos detalhes e ainda adicionou documentação
Dá para sentir que o time do Vite não está só construindo ferramentas, mas também leva a sério formação de contribuidores e colaboração
É muito bom ver esse tipo de ganho de performance na era do Electron
Um projeto que mantenho há muito tempo (começou antes dos React hooks) levava 2 minutos para buildar com react-scripts baseado em Webpack
Agora termina em 1 segundo com Vite 8. É um exemplo de quanto recurso desperdiçamos todo esse tempo
O navegador deveria conseguir executar direto, e o TypeScript também foi projetado para rodar imediatamente depois de remover apenas os tipos
A própria existência dessas ferramentas de build parece um caminho equivocado
No nosso time, depois de adotar o Vite 8, o tempo de build caiu de 4 minutos para 30 segundos
Foi quase uma substituição drop-in, e somos gratos ao time do Vite
Eu já usava antes de ser integrado ao Vite e ele é realmente excelente
O pessoal diz que é mais rápido que o Next, então se chega nisso deve ser algo enorme
Obrigado ao time do Vite por criar uma solução de bundling open source que não fica presa a um framework específico
(tosse discreta ao mencionar o Turbopack)
Ótima notícia. Mas o Next.js provavelmente não vai conseguir aproveitar esse tipo de conquista da comunidade
Por causa da síndrome do NIH da Vercel
Começou o alpha do Turbopack no Next 13 e só tornou padrão no Next 16
Em 2022, até os benchmarks comparando com o Vite foram distorcidos
Problemas de cache, performance lenta, vulnerabilidades de segurança em RSC, app router confuso e dificuldade de hospedagem fora da Vercel
Escolher Next.js é um risco
Links relacionados: discussão comparativa, histórico de cache, análise de performance, CVE de segurança, OpenNext
É estranho que a documentação oficial trate Next como padrão
Não entendo por que usar React de forma não-SPA
Ex.: Sitecore Cloud, Sanity, Contentful etc.
Com Vite+, Void Cloud, Void Framework e afins,
agora parece que vai começar o confronto entre Vercel e Void
Em especial, a demo de PRC(Server Functions) é interessante — mostra segurança de tipos de ponta a ponta do DB até a UI
Estamos estudando design de RPC com Telefunc (alternativa ao tRPC) e esperamos colaborar com o time da Void
Links relacionados: vídeo da demo de PRC, Telefunc, Vike
O Void Cloud parece ter sido construído sobre Cloudflare Workers, e ainda há pouca informação disponível
Mesmo assim, é muito animador ver que o Vite+ será publicado como open source sob MIT
Se o Bun continuar focando no apoio da Anthropic e descuidar do OSS, pode acabar perdendo vantagem competitiva
Referência: Void Cloud
Mesmo com a confusão no ecossistema JS, o Vite segue entregando excelente DX e qualidade de produção
Com o bundler Rolldown integrado, vai se tornar uma base ainda mais rápida e flexível
Como alguém que faz desenvolvimento web desde 1998, sou realmente fã
Como dou importância à manutenção de longo prazo, eu uso esbuild diretamente
Não gosto de ter que corrigir wrapper como o Vite toda vez que uma mudança interna quebra algo
Fazia a validação de tipos com Zod e gerava código só para os tipos do Postgres
Acho que depois eu teria usado Kysely
O suporte nativo a tsconfig paths é uma ótima melhoria de QoL
Dá para reduzir configuração duplicada
Dependendo do projeto, pode ser mais simples
Na verdade, JS originalmente era uma linguagem que não precisava de processo de build; o navegador deveria conseguir executá-lo diretamente, e o TypeScript também foi projetado para poder ser executado imediatamente bastando remover os tipos. A própria existência dessas ferramentas de build parece ser um caminho equivocado -> como poderíamos normalizar isso?
Como algo que antes rodava só no navegador agora passou a rodar diretamente no servidor, parece que esse era um caminho inevitável.
Acho que isso é um fenômeno natural que surgiu à medida que os web apps foram ficando mais sofisticados.
Talvez seja preciso abandonar o JS do navegador como se abandonou o Flash, não? Mas não há sinal de que o JS vá ser deixado de lado.