DEV Community

Desconstruindo o Build: A Revolução do Angular (E a diferença entre Compilador e Bundler)

Fala, comunidade dev! 👋

Na nossa jornada de migração do YMS (do Angular 16 para o 21), mencionei no primeiro artigo que o tempo de compilação e o hot reload despencaram. A experiência de desenvolvimento foi para outro patamar. Mas por que isso aconteceu?

Muitos desenvolvedores acreditam que o Angular "trocou de compilador" nas versões recentes. Mas isso é um mito. Para entender o que realmente deixou o framework tão rápido, precisamos separar duas ferramentas fundamentais que rodam no seu terminal: o Compilador e o Bundler (Empacotador).


1. Desfazendo a confusão: Compilador vs. Bundler

A. O Compilador (Ivy)
O compilador é o tradutor. O navegador não entende TypeScript, nem entende os decorators do Angular (@Component, @Injectable) ou a sintaxe de template do HTML (@if, {{ variavel }}).

O papel do compilador do Angular (chamado de Ivy) é ler esse código e transformá-lo em instruções JavaScript puras.

A grande sacada aqui é: O compilador não mudou. O Angular usa o Ivy desde a versão 9. Tanto o nosso projeto legado no Angular 16 quanto a versão nova no Angular 21 rodam o mesmíssimo compilador por baixo dos panos.

B. O Bundler (O Empacotador)
O Bundler é o gerente de logística. Depois que o Ivy traduz os arquivos, você fica com milhares de pequenos arquivos JS espalhados. O Bundler pega tudo isso, resolve as dependências (quem importa quem), aplica o Tree-Shaking (que explicamos no artigo anterior), minifica o código e empacota tudo em um ou mais arquivos finais para o navegador baixar.

E é aqui que a mágica da nossa migração aconteceu: nós trocamos o gerente de logística.


2. O Passado: A Era do Webpack

No Angular 16, o padrão absoluto para empacotar a aplicação era o Webpack.

O Webpack é uma ferramenta fantástica, mas tem um problema de arquitetura para o modo de desenvolvimento: ele precisa construir a aplicação inteira antes de poder servi-la.

Em um sistema corporativo pesado como o nosso YMS (cheio de telas, regras logísticas e componentes densos do PrimeNG), o Webpack precisava rastrear milhares de arquivos, compilar tudo, empacotar em memória e só então liberar a tela no localhost. Qualquer mudança num CSS fazia o Webpack recalcular uma parte gigantesca desse pacote. O resultado? Segundos (ou até minutos) olhando para o terminal esperando o reload.


3. O Presente: A Revolução do Esbuild + Vite

A partir das versões mais recentes (consolidado como padrão no 17+), o Angular chutou o Webpack e reescreveu todo o seu pipeline de build utilizando duas ferramentas absurdamente rápidas: o Esbuild e o Vite.

  • Esbuild: É um bundler escrito em Go (uma linguagem compilada e de altíssima performance). Ao contrário do Webpack (escrito em JavaScript), o Esbuild paraleliza o trabalho usando todos os núcleos do seu processador. Ele constrói dependências pesadas (como o PrimeNG ou o RxJS) em milissegundos.
  • Vite: Essa é a estrela do modo de desenvolvimento (ng serve). O Vite inverte a lógica do Webpack. Ele não constrói a aplicação inteira antes de iniciar. Ele inicia o servidor instantaneamente e deixa o navegador pedir os arquivos sob demanda (usando Native ES Modules). Se você está na tela de "Login", o Vite só pede para o Angular compilar e entregar os arquivos do Login. O resto do YMS fica ignorado até você navegar para lá.

4. O Impacto na Prática

Essa mudança do Webpack para o Esbuild/Vite mudou a nossa vida no projeto. O Hot Module Replacement (HMR) agora é instantâneo. Você altera a cor de um botão no arquivo SCSS, e a tela pisca e atualiza em frações de segundo, sem perder o estado da página.

Nós não escrevemos código mais rápido, mas paramos de esperar a máquina trabalhar. O ciclo de feedback rápido destrava a produtividade de qualquer equipe de Front-end.


Conclusão

O Angular 21 não é mais rápido porque tem um novo compilador, mas sim porque o ecossistema de build ao redor dele evoluiu para ferramentas de próxima geração.

Se você ainda está preso em versões antigas do Angular, atualize. Nem que seja apenas para sentir o prazer de um ng serve que inicia em menos de 2 segundos.

Você já notou essa diferença de tempo de build nos seus projetos atualizados? Quanto tempo demorava o seu ng serve mais lento na época do Webpack? Deixa aí nos comentários! 👇

Top comments (0)