Desde el primer momento en que conocí Astro me interesó su propuesta. Su nombre y logo captaron mi atención, pero sabía que eso no era suficiente para juzgar una tecnología. Lo importante era comprobar cómo respondía en un proyecto real.
Por qué Astro
Astro llegó para llenar un vacío en el vasto mundo de los frameworks de JavaScript. Al considerar qué tecnología utilizar para crear una aplicación estática con una experiencia de desarrollo moderna, lo primero que viene a la mente son opciones como Next.js, Nuxt.js, SvelteKit o Gatsby. Sin embargo, todas estas opciones dependen de enviar JavaScript al cliente, incluso cuando se trata de una web estática. Esto se debe a que funcionan como metaframeworks basados en otras tecnologías:
Qué diferencia a Astro
Aquí es donde Astro marca la diferencia: su renderizado se basa en HTML, CSS y JavaScript puro, sin la necesidad de un framework adicional. Además, su arquitectura de islas (Islands Architecture) permite integrar otros frameworks como React, Vue, Svelte, Preact, SolidJS o Alpine.js de manera inteligente, facilitando la adición de interactividad sin comprometer el rendimiento.
Mis primeras pruebas con Astro
Desde su lanzamiento quise probarlo, pero no tenía el tiempo disponible. Mi primera incursión fue migrar el blog de mi novia de Next.js a Astro. En esa prueba mantuve la misma interfaz con TailwindCSS y el CMS con DatoCMS, sin explorar todavía muchas de las características de Astro. El resultado está en nuestrashojasamarillas.com.
No fue hasta que tuve más tiempo libre (por un giro inesperado en mi vida laboral) que decidí sumergirme por completo en Astro y desarrollar mi propio sitio web desde cero. Como buen desarrollador, no podía evitar la tentación de reconstruir mi portafolio con la última tecnología que me entusiasmaba. Esta vez, quería aprovechar todas las capacidades de Astro.
Desafíos y aprendizajes
Uno de los retos más interesantes fue desarrollar todo con HTML, CSS y JavaScript puro, sin librerías de UI ni componentes predefinidos. Usé TailwindCSS para la maquetación y Zod para la validación de formularios, pero nada más. Me sentí como en los viejos tiempos, cuando construir desde cero era la norma y cada línea de código tenía un propósito claro.
Funcionalidades clave que exploré
- Enrutamiento con internacionalización (i18n) para ofrecer mi sitio en dos idiomas: es y en.
- Colecciones de contenido para gestionar el blog de manera eficiente.
Capacidades que más valoro
- Enrutamiento basado en archivos, que reduce configuración adicional y hace predecible la estructura de rutas.
- Integración nativa con Markdown y MDX.
- Componentes
.astro, simples de entender y cercanos a HTML, CSS y JavaScript. - Directivas de plantilla para añadir comportamiento sin abandonar el modelo del componente.
- Soporte para múltiples frameworks de UI, como React.js, Vue.js, Svelte, Preact, SolidJS y Alpine.js.
- Adaptadores de despliegue para Cloudflare, Netlify, Node.js y Vercel.
- Soporte para i18n sin paquetes externos.
- Colecciones de contenido para contenido estructurado.
- Estilos locales y globales con
<style>dentro de los componentes. - Integración con View Transitions API.
- Scripts de componente ejecutados en el servidor, que permiten incorporar lógica de backend sin configuración adicional.
- Rutas API para extender una aplicación sin depender necesariamente de un backend externo.
Evaluación final
Astro ha sido una de las tecnologías que más me ha impresionado en los últimos años. Ofrece buen rendimiento y una experiencia de desarrollo flexible. Para sitios de contenido y experiencias con interactividad localizada, considero que vale la pena evaluarlo.
No es una respuesta universal para cualquier producto, pero sí una opción sólida cuando el objetivo es entregar HTML rápido y reservar JavaScript para las partes que realmente lo necesitan.
Qué aprendería después
Al releer este artículo, mi entusiasmo se mantiene, pero hoy formularía la recomendación con más precisión. Astro no es rápido porque su logo represente “cero JavaScript”; es rápido cuando el equipo conserva HTML como valor por defecto, optimiza imágenes y añade hidratación con intención. También puede volverse pesado si cada sección termina siendo una isla cargada al inicio.
Content Collections se convirtió en una de las piezas que más valoro. Validar título, fecha, idioma e imagen durante el build reduce errores editoriales reales. En este mismo blog, esa validación permite exigir paridad entre español e inglés y generar rutas estáticas predecibles.
También aprendí que una buena experiencia técnica necesita detalles menos llamativos: canonical correcto, hreflang, fechas visibles, autoría, enlaces internos y un sitemap actualizado. El framework facilita producir HTML, pero no decide esos metadatos por ti.
Mi criterio actualizado es sencillo:
- Para contenido con interacción localizada, Astro sigue siendo mi primera evaluación.
- Para una aplicación dominada por estado compartido, compararía antes un framework centrado en aplicaciones.
- Para un sitio híbrido, construiría una página representativa y mediría el JavaScript y el coste operativo.
Esa postura es menos absoluta que mi primera impresión, pero también más útil: conserva lo que Astro hace especialmente bien sin convertirlo en una respuesta para cualquier producto.
Límites que no ignoraría
La libertad de mezclar frameworks puede aumentar dependencias y criterios de revisión si se usa sin una razón de migración o integración. También vigilaría adaptadores específicos de plataforma, diferencias entre renderizado estático y servidor, y cualquier feature experimental que termine sosteniendo un recorrido crítico.
Astro reduce complejidad del cliente, pero el proyecto todavía necesita una estrategia para caché, datos, despliegue y observabilidad. Elegirlo resuelve una parte importante de la arquitectura web; no sustituye las demás decisiones.
Esta experiencia fue el punto de partida. Si estás evaluando Astro para un proyecto nuevo, construye una página representativa, mide cuánto JavaScript llega al cliente y revisa qué partes necesitan realmente interacción.
La decisión también depende del producto. En código perfecto vs decisiones correctas explico por qué el contexto importa más que elegir la herramienta técnicamente más atractiva.
