Angular Reborn: esqueça o que você sabe sobre o framework

A idade das trevas que ficou pra trás

Quem trabalhou com Angular nos anos de ouro das SPAs conhece a dor de perto. Não era uma dor só de performance — era de previsibilidade. Você fazia uma mudança pequena e não sabia o que ia re-renderizar. Salvava o arquivo e esperava. Esperava mais. A barra de progresso ficava travada em 92% [chunk optimization] enquanto o café esfriava.

Três problemas concentravam a maior parte desse sofrimento:

Zone.js e o efeito cascata. O Angular antigo usava uma biblioteca chamada Zone.js pra detectar mudanças. Ela interceptava eventos do navegador — cliques, timers, requisições HTTP — e forçava o app inteiro a verificar o que havia mudado. Era como jogar uma pedra num lago: uma mudança pequena gerava ondas de re-renderização por toda a árvore de componentes. Lento. Pesado. Imprevisível.

SSR destrutivo. O Server-Side Rendering antigo resolvia o problema de carregamento inicial, mas criava outro: ele renderizava o HTML no servidor, entregava rápido pro browser — e então destruía e reconstruía todos os elementos do DOM no cliente pra adicionar interatividade. O resultado era o "Uncanny Valley" da hidratação: a tela aparecia rápido, mas piscava, perdia foco, e o usuário ficava sem poder interagir por um momento frustrante.

Webpack e os builds infinitos. Cada Ctrl+S podia significar tempo suficiente pra fazer um café. O Webpack e a velha CLI eram pesados demais pra aplicações escaláveis. Em projetos grandes, o servidor de desenvolvimento demorava minutos pra iniciar.

A trindade da performance moderna

A partir do Angular 17, o framework resolveu esses três problemas de forma estrutural. Não foram patches — foram mudanças de arquitetura.

Signals: o fim das checagens globais

A analogia mais precisa pra entender Angular Signals é uma planilha do Excel. Se a Célula A muda, apenas a Célula B — que depende dela — é atualizada. O resto da planilha não é tocado.

É exatamente isso que os Signals fazem no Angular. Em vez do Zone.js forçar o framework a checar toda a árvore de componentes, cada Signal sabe exatamente quem depende dele. A atualização é cirúrgica — só o que precisa mudar, muda.

import { signal, computed, effect } from '@angular/core';@Component({  template: `    <p>Preço: {{ precoFinal() }}</p>    <button (click)="aplicarDesconto()">Aplicar 10%</button>  `})export class ProdutoComponent {  preco = signal(100);  desconto = signal(0);  // computed só recalcula quando preco ou desconto mudam  precoFinal = computed(() =>    this.preco() * (1 - this.desconto())  );  aplicarDesconto() {    this.desconto.set(0.1); // só precoFinal será recalculado  }}

Hidratação não-destrutiva: SSR que não pisca

O Angular 17 marcou a saída da hidratação do developer preview e a tornou estável e habilitada por padrão em todos os novos apps com SSR. A mudança parece técnica, mas o impacto é completamente visível pro usuário final.

O SSR antigo destruía o DOM do servidor e reconstruía tudo no cliente. A nova hidratação reaproveita o DOM existente — o HTML que chegou do servidor é mantido, e o Angular apenas "acorda" a interatividade em cima dele, sem recriar nada.

O resultado é um First Contentful Paint ultrarrápido com interatividade contínua. Sem piscar. Sem perder o foco do campo de texto. Sem aquele momento de congelamento entre "visível" e "clicável".

O Angular 19 foi além com a hidratação incremental — usando a API @defer, componentes são hidratados sob demanda, quando o usuário precisa interagir com eles. Menos JavaScript baixado upfront, melhor performance percebida. Em testes com apps reais, o time do Angular reportou 45% de melhoria no LCP.

// app.config.ts — habilitar hidratação incremental (Angular 19+)import {  provideClientHydration,  withIncrementalHydration} from '@angular/platform-browser';export const appConfig = {  providers: [    provideClientHydration(      withIncrementalHydration()    )  ]};

<!-- O componente pesado só hidrata quando entra no viewport -->@defer (on viewport) {  <app-dashboard-pesado />}@placeholder {  <div>Carregando...</div>}

Vite + esbuild: o fim da agonia do Building...

O Angular 17 jogou o Webpack pra fora do caminho crítico e adotou Vite + esbuild como pipeline de build padrão para todos os novos projetos.

O esbuild é escrito em Go e compila centenas de milhares de linhas de código em menos de um minuto. O Vite cuida do servidor de desenvolvimento, com Hot Module Replacement que responde na velocidade do seu pensamento.

Os números são reais: o Angular reportou até 87% de melhoria no tempo de build pra projetos com hybrid rendering. O servidor de desenvolvimento inicia instantaneamente. E como o Webpack saiu do caminho crítico, o Angular CLI ficou 50% mais leve em dependências.

O novo control flow: templates que fazem sentido

Uma das mudanças mais visíveis no dia a dia é a nova sintaxe de controle de fluxo, estável desde o Angular 18. Acabou o *ngIf e o *ngFor com toda a verbosidade estrutural. Agora é direto:

<!-- Antes --><div *ngIf="usuario; else semUsuario">  <span *ngFor="let item of itens; trackBy: trackById">    {{ item.nome }}  </span></div><ng-template #semUsuario>Login necessário</ng-template><!-- Depois -->@if (usuario) {  @for (item of itens; track item.id) {    <span>{{ item.nome }}</span>  }} @else {  Login necessário}

Mais legível, melhor performance de renderização, e o track do @for é obrigatório — o que força boas práticas que antes eram opcionais e frequentemente esquecidas.