Angular Renacido: olvida lo que sabías sobre el framework

La edad oscura que quedó atrás

Quien trabajó con Angular en los años dorados de las SPAs conoce bien el dolor. No era solo un problema de performance — era de predictibilidad. Hacías un cambio pequeño y no sabías qué se volvería a renderizar. Guardabas el archivo y esperabas. Esperabas más. La barra de progreso se quedaba atascada en 92% [chunk optimization] mientras el café se enfriaba.

Tres problemas concentraban la mayor parte de este sufrimiento:

Zone.js y el efecto cascada. El Angular antiguo usaba una biblioteca llamada Zone.js para detectar cambios. Interceptaba eventos del navegador —clics, temporizadores, peticiones HTTP— y forzaba a toda la aplicación a verificar qué había cambiado. Era como tirar una piedra en un lago: un cambio pequeño generaba ondas de re-renderizado en todo el árbol de componentes. Lento. Pesado. Impredecible.

SSR destructivo. El Server-Side Rendering antiguo solucionaba el problema de carga inicial, pero creaba otro: renderizaba el HTML en el servidor, se entregaba rápido al navegador —y luego destruía y reconstruía todos los elementos del DOM en el cliente para agregar interactividad. El resultado era el "Uncanny Valley" de la hidratación: la pantalla aparecía rápido, pero parpadeaba, perdía el foco y el usuario no podía interactuar por un momento frustrante.

Webpack y los builds infinitos. Cada Ctrl+S podía significar tiempo suficiente para preparar un café. El Webpack y la vieja CLI eran demasiado pesados para aplicaciones escalables. En proyectos grandes, el servidor de desarrollo tardaba minutos en iniciar.

La trinidad del rendimiento moderno

A partir de Angular 17, el framework resolvió estos tres problemas de forma estructural. No fueron parches —fueron cambios de arquitectura.

Signals: el fin de las comprobaciones globales

La analogía más precisa para entender Angular Signals es una hoja de cálculo de Excel. Si la Celda A cambia, solo la Celda B —que depende de ella— se actualiza. El resto de la hoja no se toca.

Es exactamente lo que hacen los Signals en Angular. En lugar de que Zone.js fuerce al framework a recorrer todo el árbol de componentes, cada Signal sabe exactamente quién depende de él. La actualización es quirúrgica —solo lo que necesita cambiar, cambia.

import { signal, computed, effect } from '@angular/core';

@Component({
  template: `
    <p>Precio: {{ precioFinal() }}</p>
    <button (click)="aplicarDescuento()">Aplicar 10%</button>
  `
})
export class ProductoComponent {
  precio = signal(100);
  descuento = signal(0);

  // computed solo recalcula cuando precio o descuento cambian
  precioFinal = computed(() =>
    this.precio() * (1 - this.descuento())
  );

  aplicarDescuento() {
    this.descuento.set(0.1); // solo precioFinal será recalculado
  }
}

Hidratación no destructiva: SSR que no parpadea

Angular 17 marcó la salida de la hidratación del developer preview y la volvió estable y habilitada por defecto en todas las nuevas apps con SSR. El cambio parece técnico, pero el impacto es completamente visible para el usuario final.

El SSR antiguo destruía el DOM del servidor y lo reconstruía todo en el cliente. La nueva hidratación reutiliza el DOM existente — el HTML que llegó del servidor se conserva y Angular solo "despierta" la interactividad encima, sin recrear nada.

El resultado es un First Contentful Paint ultrarrápido con interactividad continua. Sin parpadeo. Sin perder el foco del campo de texto. Sin ese momento de congelamiento entre "visible" y "clickeable".

Angular 19 fue más allá con la hidratación incremental —usando la API @defer, los componentes se hidratan bajo demanda, cuando el usuario necesita interactuar con ellos. Menos JavaScript descargado upfront, mejor performance percibida. En pruebas con apps reales, el equipo de Angular reportó 45% de mejora en el LCP.

// app.config.ts — habilitar hidratación incremental (Angular 19+)
import {
  provideClientHydration,
  withIncrementalHydration
} from '@angular/platform-browser';

export const appConfig = {
  providers: [
    provideClientHydration(
      withIncrementalHydration()
    )
  ]
};

<!-- El componente pesado solo se hidrata al entrar al viewport -->
@defer (on viewport) {
  <app-dashboard-pesado />
}
@placeholder {
  <div>Cargando...</div>
}

Vite + esbuild: el fin de la agonía del Building...

Angular 17 sacó al Webpack del camino crítico y adoptó Vite + esbuild como pipeline de build por defecto para todos los nuevos proyectos.

El esbuild está escrito en Go y compila cientos de miles de líneas de código en menos de un minuto. Vite se encarga del servidor de desarrollo, con Hot Module Replacement que responde a la velocidad del pensamiento.

Los números son reales: Angular reportó hasta 87% de mejora en tiempo de build para proyectos con renderizado híbrido. El servidor de desarrollo se inicia instantáneamente. Y como el Webpack salió del camino crítico, el Angular CLI se volvió 50% más liviano en dependencias.

El nuevo control flow: templates que tienen sentido

Uno de los cambios más visibles día a día es la nueva sintaxis de control de flujo, estable desde Angular 18. Se acabó el *ngIf y el *ngFor con toda su verbosidad estructural. Ahora es directo:

<!-- Antes -->
<div *ngIf="usuario; else sinUsuario">
  <span *ngFor="let item of items; trackBy: trackById">
    {{ item.nombre }}
  </span>
</div>
<ng-template #sinUsuario>Login necesario</ng-template>

<!-- Después -->
@if (usuario) {
  @for (item of items; track item.id) {
    <span>{{ item.nombre }}</span>
  }
} @else {
  Login necesario
}

Más legible, mejor performance de renderizado, y el track de @for es obligatorio — lo que fuerza buenas prácticas que antes eran opcionales y frecuentemente olvidadas.