Webpack e seus concorrentes foram fantásticos para o empacotamento de projetos de front-end durante muito tempo, porém eles carregam o fardo de ser uma tecnologia com mais de 10 anos, em um contexto extremamente volátil e disruptivo como a web, entretanto hoje já não são mais a primeira opção e provavelmente vão rumar ao desuso, o motivo?

ESbuild

Diferente da maioria dos empacotadores de javascript, o esbuild resolveu atacar o problema que é ter uma linguagem JIT compiled fazendo um trabalho que contexto não se adequa, para o cenário anterior cada vez que você roda seu empacotador ele envia todo o código e suas dependencias para a VM do Javascript e chega sem nenhum tipo de otimização, precisando ser custosamente processado até que responda com um novo pacote.

Todos que desenvolvem front-end já passaram pela situação onde para precisar ver uma mudança na tela era necessário aguardar um bom tempo e as vezes até reiniciar a página, processo completamente contra intuitivo.

E como o esbuild resolve isso?

Um dos primeiros fatores foi reescrever um empacotador que fosse pensado do zero para ser o mais performático possível, o primeiro passo foi utilizar uma linguagem que fosse extremamente eficiente com paralelismo e também que fizesse a gestão da memória de maneira muito eficiente, para isso escolheram Go.

Mas sabemos que só mudar a linguagem não é uma justificativa, o empenho foi muito além disso para ter resultados, precisaram fazer estruturas de dados consistentes evitando ao máximo conversões de dados e também não utilizar nenhuma bíblioteca de terceiros, incluindo não usar o compilador do Typescript como parser e fazendo uma solução própria.

Fez parte também do empenho um uso eficiente de memória, enquanto a maioria dos empacotadores utilizam da AST por várias vezes em cada etapa de empacotamento, o esbuild só utiliza da AST por três vezes:

1. Lexing, parsing, scope setup, and declaring symbols

2. Binding symbols, minifying syntax, JSX/TS to JS, and ESNext-to-ES2015

3. Minifying identifiers, minifying whitespace, generating code, and generating source maps

Maximizando o reuso de dados, com cache quente da CPU, assim essa solução utiliza bem menos memória e tem uma resolução mais rápida, reunindo todos esses pontos podemos ter números muito relevantes em relação aos concorrentes:

Javascript

Typescript

Fonte: https://esbuild.github.io/faq/#benchmark-details

Casos de uso

Vite

Com tantos pontos positivos, não demorou muito para que surgissem abstrações usando o esbuild, hoje a mais famosa delas é o Vite, que eu particularmente acabei conhecendo pelo Shopify em uma aplicação deles que demandava muita performance na web. Acredito que o contexto onde encontrei o Vite e o tamanho engajamento dele na comunidade façam do esbuild muito popular e utilizado, dando fim então, ao webpack e aos empacotadores mais "tradicionais". Reuni alguns pontos interessantes sobre para que você fique de olho,

• Utiliza o esbuild para fazer pre carregamento e cache das dependencias

• Utiliza native ESM para entregar mudanças menores por módulo, onde ao invés de um bundle inteiro gerado, é gerada uma mudança por módulo de rota. Recurso que ele chama de HMR, hot module reload.

• É muito mais rápido e simples que o Webpack

• Está preocupado com compatibilidade além de rapidez

• Usa o Rollup para produção por debaixo dos panos, biblioteca consolidada.

Vale citar também o turbopack, que conta com Tobias Koppers, criador do webpack, para revolucionar ainda mais que o Vite, que prefere ser conservador para empacotamento em produção, no turbopack tudo será escrito em Rust inclusive o empacotador para ser ainda mais performático.