Si quieres aplicar Server-side rendering en Angular y aprovechar mejoras como Incremental hydration o detección de cambios basada en signals, necesitas usar los nuevos builders de Angular. Aquí entenderás qué builder usar, cómo migrar al Application Builder y qué cambia en tu carpeta de salida cuando lo haces.

¿Qué builders ofrece Angular y cuál deberías usar?

Angular CLI ofrece cuatro builders distintos para construir tu aplicación, y cada uno responde a un escenario diferente. Saber cuál estás usando te ayuda a decidir si vale la pena migrar.

• Application: el más recomendado. Permite client-side rendering y Server-side rendering en el mismo builder, usa ESBuild y concentra todas las innovaciones recientes del equipo de Angular.
• Browser ESBuild: genera solo client-side. No soporta SSR, pero ya usa ESBuild en lugar de Webpack.
• Browser: la opción legacy basada en Webpack. Útil si tienes integraciones específicas con Webpack que no puedes mover.
• SSR builder legacy: opciones anteriores para renderizado en servidor antes de la unificación en Application.

La recomendación es clara: muévete a Application. Ahí está el futuro de Angular y ahí es donde podrás activar SSR sin saltar a otro builder más adelante.

¿Por qué ESBuild es mejor que Webpack en Angular? Porque ESBuild está escrito en Go y transpila mucho más rápido. En proyectos grandes con muchos servicios la diferencia en tiempo de build es notable [01:50].

¿Cómo saber qué builder estás usando hoy?

La respuesta vive en un solo archivo: angular.json. Ábrelo y revisa la propiedad builder dentro de la configuración de build. Ahí verás explícitamente si estás corriendo el legacy de Webpack, Browser ESBuild o ya estás en Application.

Un proyecto con el builder de Webpack funciona sin problemas: soporta signals, renderiza del lado del cliente y compila bien. El punto no es que esté roto, sino que te estás perdiendo rendimiento y la puerta de entrada a SSR.

Cómo se ve un build antes de migrar

Si ejecutas ng build con el builder legacy, Angular genera la carpeta dist con una subcarpeta del nombre del proyecto (por ejemplo, store) y dentro encuentras directamente el index.html y los archivos JavaScript minificados. Esa estructura plana es la que tu equipo de DevOps probablemente está subiendo a GitHub Pages, S3 o Netlify.

Recuerda que los navegadores no entienden TypeScript ni Angular como tal. Todo framework moderno (Angular, React, Vue, Next) transpila el código a JavaScript final antes de enviarlo al browser. Por eso el builder importa tanto: define qué tan rápido y qué tan bien empaquetado sale ese resultado.

¿Cómo migrar al Application Builder en Angular?

La migración oficial está documentada en la sección Angular CLI > Application Build System de la documentación. Angular ofrece un comando que analiza tu configuración actual y aplica los cambios automáticamente, sin que tengas que tocar manualmente el angular.json [05:10].

Los pasos son simples:

1. Ejecuta el comando de migración oficial en tu terminal desde la raíz del proyecto.
2. Revisa los cambios en angular.json: el builder pasa de browser a application y el outputPath se reorganiza.
3. Confirma que el campo main ahora aparece como browser dentro de la configuración.
4. Corre ng build para validar que todo compila correctamente.

La migración manual también está documentada por si el comando falla, aunque en la práctica casi siempre funciona sin intervención.

¿Qué hace exactamente el comando de migración a Application? Cambia el builder en angular.json, ajusta el outputPath y renombra la entrada principal. Son cuatro modificaciones puntuales, no toca tu código fuente.

¿Qué cambia en la carpeta dist después de migrar?

Aquí está el detalle que puede romper tu deployment si no lo comunicas a tiempo. Antes, tu index.html vivía directamente en dist/store/. Después de migrar a Application, Angular crea una subcarpeta adicional llamada browser dentro de la salida [07:30].

La nueva estructura queda así:

• dist/store/browser/: contiene el index.html y los archivos client-side.
• dist/store/server/: aparecerá cuando actives SSR, con los artefactos del servidor.

Este cambio existe porque Application puede generar los dos tipos de salida en el mismo build. Angular separa lo que va al navegador de lo que va al servidor para que tu pipeline de despliegue sepa qué subir a cada destino.

Por qué este cambio puede romper tu deployment

Si tu equipo de DevOps tenía un script que copiaba todo el contenido de dist/store/ a un bucket de S3 de Amazon, a GitHub Pages, Netlify, Amplify o Firebase Hosting, ese script ya no encontrará el index.html en la ruta esperada. La aplicación se desplegará vacía o con errores 404.

La solución es ajustar la ruta de despliegue agregando /browser al path de origen. Es un cambio mínimo, pero crítico. Si tú eres quien hace el deployment, anótalo. Si trabajas con un equipo de DevOps, comunícalo antes de hacer merge a la rama principal.

Una vez completada la migración, tu proyecto queda listo para activar Server-side rendering en la siguiente etapa, con un builder más rápido, salida organizada y acceso a las funcionalidades modernas del framework.

¿Ya migraste al Application Builder en alguno de tus proyectos? Cuéntame en los comentarios qué diferencias notaste en tiempos de build.