Astro

Astro es un framework web de código abierto construido sobre una regla simple: una página es HTML hasta que algo en ella tiene que ser interactivo. Los componentes se renderizan en el servidor en tiempo de build, el navegador recibe marcado y CSS, y el JavaScript de cliente se limita a los componentes concretos que lo necesitan, el patrón que su documentación llama islas.

Ese comportamiento por defecto es la razón por la que lo elegimos en trabajo de contenido. Un sitio de marketing, un conjunto de documentación o una publicación se leen muchas más veces que se usan, y un framework que manda el runtime completo de una aplicación para renderizar un párrafo está pagando por lo que no toca. Las páginas hechas así arrancan rápido en un móvil de gama media y con una conexión lenta, que es donde está la mayor parte del tráfico real.

También es agnóstico respecto al framework cuando eso ayuda. Un componente que ya existe en React, Vue o Svelte se puede montar en una página de Astro e hidratarse por su cuenta, así que un equipo que ya ha invertido en uno de ellos no tiene que reescribir su librería de componentes para llevar un sitio a Astro.

El contenido está tipado en lugar de suelto. Las content collections validan cada entrada contra un esquema en tiempo de build, así que un campo que falta o una fecha mal formada rompen el build en lugar de llegar a producción como un elemento vacío. Es el mismo argumento de TypeScript, aplicado a los textos.

Lo que nos aporta en un proyecto típico:

• Salida estática que se despliega en un CDN o en almacenamiento de objetos, sin servidor que parchear, o renderizado en servidor mediante un adaptador cuando una ruta necesita ser dinámica de verdad.
• Contenido validado contra esquema, para que los errores de edición salgan en CI y no en la página.
• Control página a página de qué se envía al navegador, lo que mantiene las Core Web Vitals como una propiedad de la arquitectura en vez de algo que se persigue después del lanzamiento.
• Resuelto de serie lo que todo sitio de contenido necesita igualmente: optimización de imágenes, sitemaps, RSS, redirecciones y escritura en Markdown o MDX.
• Un modelo de componentes lo bastante cercano a HTML y CSS como para que un diseñador pueda leer una plantilla, y un proyecto que el equipo del cliente puede acabar llevando.

No es la elección correcta para todo, y lo decimos antes de que se elija. El trabajo con forma de aplicación (un panel, un espacio autenticado, cualquier cosa donde la mayor parte de la pantalla tiene estado) pertenece a React o a Angular, y forzarlo dentro de un framework de contenido produce una versión peor de las dos cosas. Lo mismo con un sitio cuyos editores necesitan un CMS al que haya que conectar Astro: esa integración es trabajo real y conviene presupuestarla al principio en lugar de descubrirla tarde.

Cuando un proyecto es de verdad mixto, un sitio público rápido más un área privada pequeña, esa frontera suele ser la costura correcta sobre la que diseñar, y preferimos trazarla a propósito antes que acabar con un único framework haciendo mal los dos trabajos.