Qué es Astro, su enfoque técnico y cómo funciona

Hasta hace poco, cuando montaba una web corporativa, lo habitual en mi caso y en el de casi todos era recurrir a WordPress. Por motivos obvios: es fácil, tienes desarrollado casi todo lo que necesitas y además, tras muchos años, mi flujo de trabajo es muy rápido.

Pero en el último proyecto que he desarrollado, la web de Rondabus, utilicé Astro. 

¿El motivo? 

Que lo recomendaban en una newsletter sobre IA que sigo, ya que se integra muy bien con los agentes, decían.

Y vaya si lo hace.

Tomé el proyecto sobre todo como una prueba del estado del desarrollo web actual. Para comprobar cuánto depende de un humano y cuánto se puede hacer ya con la IA. Y por eso utilicé el framework recomendado.

Obviamente me documenté para entender si servía para lo que quería. Y de esa documentación, nace este artículo, en el que te cuento lo que necesitas saber para animarte con él. Y algo más.

Pero antes de entrar al asunto, un par de cositas:

La primera es que flipé con su enfoque HTML first. Es justo lo que llevaba años pregonando.

Lo segundo es que, a fecha de hoy y para desarrollar una web, salvo el criterio, todo lo demás lo pone ChatGPT o Claude.

Ahora sí, empezamos.

Qué es Astro exactamente

Astro es un framework para construir sitios web, es decir, un conjunto de herramientas y directrices que te ayuda a generar el código de tu web.

Ni más, ni menos.

Hay muchos, cada uno con sus particularidades. En este caso te cuento las suyas.

Astro permite trabajar con piezas reutilizables, datos compartidos y plantillas. Después combina todo para producir la web.

Es decir, piensa en lo que necesitas para montar la web de una empresa: cabecera, menú, páginas de servicios, fotografías, textos, formulario y pie. Podrías escribir cada página a mano en HTML, pero repetirías mucho trabajo. 

Si cambias el teléfono, añades un elemento al menú o un enlace en el footer, tendrías que corregirlo en todos los archivos de la web. Con Astro no, ya que reutiliza elementos.

Y me dirás que como en WordPress. Y sí, es cierto, pero aquí no hay base de datos detrás.

Me podrías que responder que como en cualquier lenguaje de servidor como PHP, a lo que te responderé que no hace falta tener montado ningún lenguaje en el servidor, solo guardados los archivos. 

Como se hacía originalmente, con un archivo HTML por URL y sus CSS y JS anexos.

De hecho, puedes utilizar HTML, CSS y JavaScript o TypeScript, pero también puedes incorporar componentes de React, Vue o Svelte si los necesitas, cosa que yo no hago.

¿Y cómo se consigue esto de elementos reutilizables y muchos HTMLs?

La diferencia fundamental: generar la web antes de que llegue el usuario

Para entender Astro conviene separar los dos momentos de una web:

1. Cuándo se desarrolla.
2. Cuándo la visita alguien .

En una web dinámica tradicional, el servidor prepara la página cuando recibe una petición. Ejecuta código, obtiene los datos necesarios, los coloca en una plantilla y devuelve el resultado al navegador.

WordPress por ejemplo trabaja así: PHP ejecuta la aplicación, consulta su base de datos y utiliza el tema y los plugins para generar la página. Sí, la caché permite guardar una respuesta y reutilizarla, por lo que no hay que repetir todo el proceso en cada visita, por lo importante es  entender que existe una aplicación capaz de fabricar la respuesta mientras la web está funcionando.

Sin embargo, con Astro puedes hacer ese trabajo antes de publicar. Preparas las páginas, generas los archivos y colocas el resultado en el alojamiento. Es lo que se llama una build.

Así, cuando alguien entra en la página de contacto, el servidor entrega un HTML que ya estaba hecho. No necesita reconstruir la cabecera, recuperar el teléfono y montar el pie para ese visitante.

Esta manera de trabajar se llama SSG, o generación de sitios estáticos. Y tienen varias ventajas, como que, literalmente, vuelan.

Hay más que te explico en el artículo. 

Con lo que te he contado hasta ahora te sirve para hacerte una idea de lo que estamos hablando, si no eres técnico. Si lo eres, a partir de ahora, profundizamos en cómo trabaja el framework.

Café para cafetero. Avisado estás.

Hablemos de las builds

Lo primero es que entiendas que una build no es más que el resultado de un proceso automatizado que toma todos los archivos que has escrito (código, imágenes, estilos) y los transforma en un paquete listo para que el servidor o el navegador web los puedan ejecutar.

Y ya.

Es decir, tu tienes una serie de archivos con código que hacen distintas cosas. Al ejecutar el comando para compilar la build, Astro identifica las páginas, obtiene el contenido, ejecuta las plantillas y prepara los recursos, para, finalmente, devolverte una web estática completa, con sus HTML, CSS y JS (si los necesita).

Por ejemplo, puedes tener una plantilla común y ocho fichas de servicios. El build combina la plantilla con los datos de cada ficha y produce las páginas correspondientes.

En Astro se realiza con el comando npm run build y el paquete resultante se denominará astro build. La web preparada para subir está en la carpeta dist lista para subirse al servidor donde tengas apuntado el dominio.

Cómo se construye una página en Astro

Si no estás acostumbrado, el vocabulario parece más complicado de lo que es. Vamos a verlo con una pequeña web de empresa.

Cómo es un archivo .astro

Un archivo .astro puede combinar una parte de código con una plantilla parecida a HTML:

—

const titulo = ‘Transporte para tu empresa’;

—

<h1>{titulo}</h1>

<p>Organizamos los desplazamientos de tu equipo.</p>

Lo que aparece entre los dos grupos de guiones prepara los datos. Debajo está la plantilla que los utiliza. Las llaves indican dónde introducir un valor.

Ese código se ejecuta al construir la web y el navegador recibe un encabezado con su texto y un párrafo normales, con el contenido de la variable titulo.

Componentes

Los elementos que se reutilizan. 

Por ejemplo, la cabecera puede ser un componente. El pie, otro. Una plantilla del módulo del hero banner de las páginas de servicio, otro. Los guardas por separado y los utilizas en las páginas que los necesitan.

Por ejemplo, una página puede importar Header.astro y Footer.astro y colocar <Header /> al principio y <Footer /> al final. Astro convierte esas piezas en el marcado HTML correspondiente.

Props

Las props son los datos que entregas a un componente para que pueda reutilizarse con contenido distinto.

Si has creado una componente para el módulo del hero banner de las páginas de servicio, puedes pasarle un título, una descripción y una imagen. La estructura conserva su diseño mientras cambian los valores. Así, el módulo hero del servicio 1 es una y el del del servicio 2, otra con contenido diferente, pero mismo diseño.

En Astro, el componente puede leer esos valores mediante Astro.props. 

Layouts y slots

Un layout es una estructura compartida por varias páginas. Digamos que es como un componente venido a más: un componente suele ser una parte pequeña de la URL mientras que el layout es prácticamente todo.

Puede incluir el documento HTML, los metadatos, la cabecera y el pie.

El slot es el hueco donde se coloca el contenido propio de cada página. 

Si vienes de WordPress, te recordará a las plantillas que comparten cabecera y pie mientras que el contenido principal varía entre URLs. No funciona exactamente igual, pero cumple una función parecida: evitar reconstruir lo común cada vez.

Cómo organiza Astro las URLs

Astro utiliza un sistema de rutas basado en archivos. En un proyecto sencillo, la ubicación de una página dentro de src/pages determina su dirección:

Archivo	Ruta
src/pages/index.astro	/
src/pages/contacto.astro	/contacto
src/pages/servicios/bodas.astro	/servicios/bodas

La barra final depende de la configuración y del alojamiento, pero la relación básica es esa.

No necesitas crear manualmente un archivo distinto para cada artículo o servicio. Eso permite generar muchas páginas a partir de una plantilla y un conjunto de datos, sin copiar el mismo código una y otra vez.

Dónde se guarda el contenido si Astro no tiene base de datos

Que Astro no exija una base de datos significa que los textos y datos tienen que guardarse en algún tipo de fuente, puedes elegir cuál.

Archivos, Markdown, JSON y YAML

Para un sitio pequeño, parte del texto puede estar en las propias páginas. Los datos compartidos, como el teléfono, conviene separarlos para no tener que corregirlos en veinte lugares.

Un artículo puede guardarse en Markdown, un formato de texto con marcas sencillas para títulos, listas y enlaces. JSON y YAML sirven para organizar datos: fichas de servicios, información de vehículos o textos por idioma, por ejemplo.

Son formatos distintos para necesidades distintas. No tienes que utilizar todos ni convertir cada frase de tu web en una estructura complicada.

Content Collections

Las Content Collections, o colecciones de contenido, ayudan a organizar conjuntos de entradas de datos y definir su estructura.

Imagina una colección de servicios en la que cada ficha debe tener título, descripción y una imagen. Puedes establecer esas reglas y validar los datos, de modo que sea más fácil detectar una ficha incompleta o un valor del tipo equivocado.

Si conoces los tipos de contenido y los campos personalizados de WordPress, la idea de organizar fichas te resultará familiar.

Contenido avanzado: APIs, CMS y bases de datos externas

Aunque estemos generando webs estáticas, lo cierto es que el contenido también puede llegar de un CMS, una API o una base de datos. Una API es una forma de que dos sistemas intercambien información: Astro pide unos datos y el otro sistema se los entrega.

Puedes utilizar incluso WordPress como fuente de artículos y construir la parte pública con Astro. Volveremos sobre esta combinación en Astro vs WordPress.

La pregunta decisiva es cuándo recuperas esa información. Si se incorpora durante el build, cambiarla en la fuente no modifica el HTML publicado hasta que lo regeneres. Si se consulta durante una petición o desde el navegador, el comportamiento es diferente y más parecido a lo que son las páginas dinámicas tradicionales.

Qué son las Islands de Astro

Una página puede tener mucho contenido que solo necesitas leer y una pequeña parte con la que quieres interactuar. Por ejemplo, una calculadora de presupuesto dentro de una página de servicio. O un formulario.

La arquitectura de islas permite que ese componente tenga su propio comportamiento sin convertir toda la página en una aplicación ejecutada en el navegador.

Qué significa hidratar un componente

Hidratar consiste en añadir el código de un componente interactivo a un HTML que ya se ha generado, para que pueda responder a acciones del usuario.

La calculadora o el formulario pueden mostrarse al cargar la página y después activar su lógica. 

Aquí estamos hablando de islas de cliente. Astro también dispone de islas de servidor para resolver partes dinámicas por separado, aunque no hace falta entrar en ellas para entender esta primera explicación.

Cuándo necesita JavaScript el navegador

No toda interacción exige una isla. Un enlace funciona con HTML. Un desplegable sencillo de un menú puede resolverse con HTML y CSS.

En cambio, una calculadora que actualiza resultados mientras cambias opciones suele necesitar JavaScript. Y el formulario necesita una integración o lenguaje de servidor para enviar los datos. 

Y aquí me encanta el enfoque de Astro: la decisión se toma por la función que quieres ofrecer, no por la idea muy manida de que una web moderna deba cargar una aplicación entera.

Astro intenta enviar cero JavaScript por defecto

Ojo no nos confundamos: hablamos de cara a la web que ve el usuario. 

Porque Astro sí utiliza JavaScript para trabajar y compilar, pero los componentes .astro no necesitan enviar su código de preparación al navegador. 

Los scripts que añadas, las islas que hidrates y las herramientas externas sí pueden incorporar JavaScript. Un chat, una plataforma de analítica (GA4) o un vídeo incrustado lo necesitan.

Por tanto, «cero JavaScript por defecto» es el punto de partida, no es ninguna obligación.

Y, como te comento más abajo, a mi me encaja muchísimo con el desarrollo de webs corporativas, por ejemplo.

Astro no solo puede ser estático, también dinámico o híbrido

Bien, hasta ahora me he centrado en un solo enfoque pero hay dos posibles.

SSG

Lo que hemos visto hasta ahora: la página se genera antes de las visitas, durante la construcción. 

Es perfecto cuando el contenido puede permanecer igual para todos hasta la siguiente publicación. Es decir, para páginas que no cambian mucho.

SSR

La página se genera en el servidor bajo demanda. Puede utilizar información que no está durante el build, como datos asociados a una sesión. 

Ya no vale cualquier servidor, necesitas un entorno de ejecución compatible y el adaptador correspondiente.

Renderizado híbrido

Puedes combinar páginas prerenderizadas y páginas bajo demanda. Por ejemplo, mantener las páginas públicas preparadas y resolver una zona privada en el servidor.

Qué papel tienen Node.js y Vite

Node.js permite ejecutar JavaScript fuera del navegador. En un proyecto habitual de Astro participa en el desarrollo y la construcción de la build, donde npm ayuda a gestionar paquetes y comandos, pero no es necesario tenerlo operativo en el servidor de producción donde alojamos la build.

Vite es un motor usado por muchos frameworks modernos. Es parte de la maquinaria que Astro utiliza para trabajar con los archivos y ofrecer el entorno de desarrollo. 

Suficiente para que te hagas una idea.

Cómo se organiza un proyecto Astro

Cuando abras un proyecto, verás carpetas que no son páginas y archivos que no se publican. Este pequeño mapa te ayudará a distinguirlos.

src

Contiene el código fuente: páginas, componentes, layouts y otros archivos de trabajo. Es donde se construye buena parte de la web.

public

Contiene recursos que se sirven sin el procesamiento habitual de los archivos importados: un robots.txt o determinadas imágenes, por ejemplo. Lo que pongas aquí será público, por lo que no es un lugar para credenciales.

package.json

Describe el proyecto, sus dependencias y sus scripts. Ahí se define qué ejecutan comandos como npm run build. El archivo de bloqueo de dependencias ayuda a conservar versiones concretas para repetir la instalación.

node_modules

Es la carpeta donde se instalan los paquetes que necesita el proyecto. Normalmente se reconstruye a partir de los archivos de dependencias y no se guarda entera en Git.

dist

Contiene la salida a producción después del build. Para una web estática, aquí encontrarás los archivos preparados para publicar.

Qué carga realmente el navegador y Google

Voy a repetirlo una vez más para los de la última fila: el navegador no recibe tu proyecto tal como lo ves en el editor. Recibe el HTML y los recursos necesarios para mostrar y utilizar la página.

Un buscador que solicita esa URL recibirá el HTML, tanto si lo preparaste durante el build como si lo generaste en el servidor. Eso no asegura que lo indexe ni que lo posicione bien: todavía importan los contenidos, los enlaces y la configuración de rastreo e indexación, pero, en mi experiencia, se puede optimizar muy, muy bien lo que recibe.

La idea con la que quiero que te quedes es esta: todas esas plantillas, colecciones y componentes sirven para producir una web que sigue utilizando las tecnologías de siempre. Astro dirige la creación de la web, el HTML resultante lo recibe un navegador.

Conclusión: para qué tipo de webs tiene sentido Astro

Esta forma de trabajar encaja bien en webs donde el contenido no se modifica en exceso: 

• Sitios corporativos.
• Portfolios
• Páginas de captación. 

No lo recomendaría para revistas, blogs y webs en las que se cree mucho contenido o trabajen distintos creadores de contenido. Para eso me sigo quedando con WordPress por delante de Astro.

Si te ha gustado el enfoque y quieres saber más, puedes continuar leyendo sobre las ventajas y desventajas de Astro.

Y si prefieres aterrizarlo en un proyecto completo, he preparado el proceso de crear una web de negocio local con IA, utilizando mi último proyecto como ejemplo.

Te garantizo que una vez que lo pruebes, ya no hay marcha atrás.