Contexto
Salvar um arquivo e esperar o navegador atualizar é a experiência que mais separa Vite de webpack no dia a dia — e a razão dessa diferença de velocidade está inteira na arquitetura por trás de cada um. webpack nasceu num momento em que empacotar tudo antes de servir era a única opção viável: ele constrói um grafo completo de dependências e produz um (ou vários) bundle antes de qualquer coisa chegar ao navegador, tanto em desenvolvimento quanto em produção. Vite nasceu depois que os navegadores passaram a suportar módulos ES nativamente, e aproveita isso: em desenvolvimento, ele não empacota nada — serve cada módulo sob demanda, deixando o próprio navegador resolver os imports, e só compila o que a tela atual realmente precisa.
Essa diferença arquitetural é a razão do dev server do Vite arrancar quase instantaneamente mesmo em projetos grandes, enquanto o do webpack precisa montar o bundle inicial antes de servir a primeira página. Para build de produção, porém, servir módulo por módulo deixa de fazer sentido — e é aí que os dois se aproximam: Vite usa um bundler de verdade por baixo do capô para gerar os artefatos finais. Esse motor, que historicamente dividia o trabalho entre um pré-empacotador de dependências e um bundler para o build, hoje é o Rolldown — um bundler unificado escrito em Rust que, a partir da versão 8, já é o padrão tanto para dev quanto para build, aproximando a velocidade de build da velocidade que o dev server já tinha.
Quando escolher Vite
Vite compensa em qualquer projeto novo baseado em módulos ES, onde o ganho de velocidade no dia a dia — cada salvamento de arquivo refletindo quase instantaneamente no navegador — importa mais do que compatibilidade com uma configuração de bundler herdada:
// vite.config.ts
import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";
export default defineConfig({ plugins: [react()] });
A configuração típica cabe em poucas linhas porque Vite já assume convenções razoáveis para a maioria dos projetos front-end modernos — servir arquivos estáticos, resolver imports de CSS e assets, aplicar HMR automaticamente. Ele também é compatível com boa parte do ecossistema de plugins criado originalmente para o Rollup, o que reduz a lacuna de plugins específicos que Vite ainda não tem em relação ao webpack. O ponto de atenção é justamente esse: para casos de borda muito específicos — transformações de build incomuns, integração com ferramentas legadas que só falam a linguagem de loaders do webpack — o ecossistema do Vite ainda é mais novo e menos exaustivamente testado em produção.
Quando escolher webpack
webpack compensa quando o projeto já existe, já tem uma configuração de build madura investida ao longo de anos, ou precisa de um comportamento muito específico que só um loader ou plugin do ecossistema webpack resolve:
// webpack.config.js
module.exports = {
entry: "./src/index.js",
module: { rules: [{ test: /\.css$/, use: ["style-loader", "css-loader"] }] },
};
Essa explicitação de regras — cada tipo de arquivo precisa de um loader dizendo como transformá-lo — é ao mesmo tempo o ponto forte e o ponto fraco do webpack: dá controle granular sobre cada etapa do pipeline, mas exige mais configuração manual para casos que outras ferramentas já resolvem por convenção. Em compensação, foi por quase uma década o bundler de referência do ecossistema JavaScript, e essa base instalada continua enorme — loaders e plugins para praticamente qualquer cenário imaginável, incluindo suporte robusto a navegadores mais antigos e pipelines de build corporativos complexos que já existem há anos e não vão ser reescritos por causa de um dev server mais rápido.
Veredito
Se seu time já está em Vite 8, a resposta sobre motor de build já está dada: o Rolldown, bundler unificado escrito em Rust, é hoje o padrão tanto para dev quanto para build. Mas escolher só por velocidade diz cada vez menos — o gargalo histórico do webpack em produção vem encolhendo em todo o ecossistema, que migra para bundlers escritos em linguagens de sistemas. O que separa os dois hoje é lastro: webpack carrega anos de configurações, loaders e conhecimento institucional acumulado em projetos existentes, e reescrever esse investimento raramente compensa só pela promessa de um dev server mais ágil. Para um projeto que está nascendo agora, sem esse lastro para carregar, começar pela ferramenta que já assume as convenções certas por padrão costuma poupar mais tempo do que qualquer configuração customizada resolveria depois.