Astro, el framework web que combina lo mejor de lo estático y lo dinámico

Conceptos previos

Los siguientes son algunos conceptos usados comúnmente en la jerga del desarrollo web, que leerás en la documentación de Astro, y necesitas conocer previamente.

Hidratación (hydration)

En el desarrollo web, la «hidratación» es el proceso por el cual JavaScript «toma el control» de un HTML que ya está renderizado en la página, para hacerlo interactivo.

Pongamos como ejemplo un carrusel, con sus botones derecha e izquierda para cambiar de fotografía o desplazar el carrusel. Todo ese HTML por sí solo es inerte, los botones no funcionan hasta que JavaScript entra en juego. La hidratación es el momento en que el navegador descarga el JavaScript de React, lo ejecuta, y «conecta» ese código con el HTML que ya existía — a partir de ahí los clics sí responden, el estado interno funciona, etc.

«Opt-in» (frente a automático)

Opt-in significa que algo no ocurre por defecto — tienes que pedirlo explícitamente. Es lo contrario de opt-out (donde algo pasa por defecto y tienes que desactivarlo a propósito).

Aplicado a Astro: en un framework tradicional de React, la hidratación es automática — tú pones un componente y React lo hidrata sin que tú tengas que decir nada, es el comportamiento por defecto de todo el árbol de la aplicación.

En Astro es al revés: por defecto, ningún componente se hidrata — se queda como HTML estático e inerte, aunque esté escrito en React. Si quieres que se hidrate, tienes que «optar» activamente por ello añadiendo una directiva de cliente.

Arquitecturas SPA (Single Page Application) vs MPA (Multi Page Application)

MPA es la arquitectura usada tradicionalmente en la web. El usuario pincha en un enlace y el servidor le entrega una página HTML completa y distinta. Cada vista es un documento independiente que el navegador carga por separado.

Conviene no confundir esto con la generación de contenido: una MPA moderna no necesita una página escrita a mano por cada vista. Si tienes artículos clasificados por categoría, el servidor genera cada página de categoría automáticamente a partir de una plantilla y una consulta a la base de datos (así funciona WordPress, por ejemplo, que es MPA). Lo que caracteriza a la MPA no es ser manual ni estática, sino que cada navegación entrega un documento HTML nuevo desde el servidor.

SPA es la arquitectura que se popularizó para aplicaciones web con mucha interactividad (paneles de control, aplicaciones tipo correo web). En ella, el servidor entrega al cliente una sola página. A partir de ahí, el cliente pide únicamente datos al servidor, y el navegador usa JavaScript para modificar la página, añadiendo o eliminando componentes sin recargar el documento. La página cambia porque JavaScript la cambia, y el usuario permanece siempre en el mismo documento.

React o Vue son librerías de interfaz que se popularizaron como base de las SPAs, aunque no están atadas a ese modelo: hoy los mismos React y Vue se usan también en arquitecturas MPA e híbridas mediante frameworks como Astro, Next.js o Nuxt.

La paradoja: el regreso a las MPA y los nuevos enfoques híbridos

La SPA nunca llegó a sustituir a la MPA en la web orientada a contenido. Y en los últimos años el péndulo ha vuelto hacia la MPA por una razón de peso: la carga inicial. Una MPA entrega HTML listo para mostrar y muy poco JavaScript, lo que se traduce en mejores tiempos de carga y menor coste para el navegador; y eso importa: menor tasa de abandono, mayor conversión en e-commerce, etc.

Por ello han aparecido enfoques híbridos, en los que disponemos de una aplicación MPA con características de SPA —como la construcción de componentes con React— manteniendo el enfoque multipágina. Tal es el caso del framework Astro.

El edge

El «edge» o borde de la red se refiere a dónde se ejecuta tu código geográficamente.

Correr código en el «edge» (perímetro o borde de la red) significa ejecutar tus funciones y aplicaciones directamente en los centros de datos distribuidos por todo el mundo, muy cerca del usuario final, en lugar de depender de un único servidor central.

El código corre en cientos de centros de datos repartidos por todo el mundo, muy cerca de la persona que visita tu sitio web.

La ventaja principal de este enfoque consiste en que los datos viajan menos distancia, lo que reduce el tiempo de espera.

CDN (Red de Distribución de Contenidos)

Una CDN (Red de Distribución de Contenidos) es una red de servidores repartidos por el mundo.

Una CDN utiliza servidores en el «edge» (el borde de la red) para acercar la información a los usuarios y acelerar las páginas web.

Cloudflare Workers es un ejemplo de CDN que ejecuta código en el edge.

¿Qué es Astro?

Astro es un framework web de renderizado híbrido, moderno y optimizado para crear sitios rápidos orientados al contenido. Elimina el JavaScript innecesario del lado del cliente mediante su arquitectura de «islas» y permite usar componentes de React, Vue o Svelte de forma flexible.

En pocas palabras, si quieres un sitio óptimo para el SEO, veloz como el viento, con las ventajas de las webs tanto dinámicas como estáticas, tal vez tu herramienta sea Astro.

Astro es, además, un proyecto de software libre (open-source).

Los sitios estáticos tienen limitaciones que los dinámicos superan. Estas pueden hacer que un sitio estático no sea lo adecuado para tu proyecto. Sin embargo, como leerás más adelante, algunas de estas limitaciones son superadas por Astro. Este puede crear sitios web de arquitectura híbrida, con características propias de sitios dinámicos. Astro combina ambos modelos de renderizado en el mismo sitio.

Relacionado: Lee Sitios estáticos vs dinámicos para comprender las diferencias.

Características principales

• Cero JavaScript por defecto: Envía HTML puro al navegador para máxima velocidad.
• Islas de contenido: Carga componentes interactivos solo cuando es necesario.
• Agnóstico de UI: Soporta React, Svelte, Vue, Solid y más en un mismo proyecto.
• Orientado a contenido: Ideal para blogs, sitios de marketing y documentación

Renderizado en servidor a demanda (server-side rendering, SSR)

Donde el contenido estático no llega, el SSR es su complemento perfecto. Imagina, por ejemplo, que un usuario logueado trata de ver su información personalizada; Astro no tiene preparado ese HTML de antemano, así que ejecuta el código de la página en ese momento, generando el documento HTML a petición.

Conviene distinguir aquí dos conceptos que suelen confundirse. Astro es server-first por diseño: su filosofía es renderizar en el servidor por defecto. Pero ser server-first no implica ser dinámico; un sitio Astro puede ser server-first y, aun así, totalmente estático (SSG). El SSR, o renderizado a demanda, es el paso siguiente: generar el HTML en el momento de cada petición, cuando el contenido no puede prepararse de antemano.

En este punto, Astro ocupa un lugar intermedio muy interesante entre un sitio puramente estático y una aplicación web dinámica tradicional. El servidor genera el documento HTML a petición.

Astro permite incluso que solo una pequeña parte de una página se renderice dinámicamente en el servidor, gracias a su característica Server Islands, una de cuyas implementaciones más destacadas ha impulsado el propio Astro. El resto de la página puede permanecer estático y cacheable. Por tanto, permite decidir por página si se sirve estática (SSG) o renderizada en servidor (SSR), en el mismo proyecto.

Lógicamente, esta característica de generación dinámica requiere un runtime de servidor y un adapter apropiado. Aquí viene la parte interesante:

1. Esto puede lograrlo a un coste entre muy bajo y ninguno, usando plataformas como Cloudflare (Pages o Workers) o Netlify, ambas con soporte para SSR. Con estas no necesitas necesariamente alquilar un VPS y mantener un proceso Node corriendo 24/7.
2. No necesitas en principio aprender un lenguaje de programación de lado servidor, como Python, PHP, etc.

Fácil de usar

Diseñado para ser sencillo y cercano a cualquier desarrollador web, porque:

• El lenguaje UI Astro es un superconjunto de HTML, lo que significa que si puedes escribir HTML, puedes escribir componentes Astro.
• Además, puedes usar el lenguaje de componentes UI que ya conozcas: React, Preact, Svelte, Vue, Solid, componentes web, …

¿Qué significa todo esto en la práctica, y cuales son las limitaciones reales de Astro?

¿Puede Astro tener sus propios formularios en vez de incrustar externos con servicios como los de Formspree/Formsubmit/Formsubmit? ¿Cual es realmente la diferencia entre alojar Astro en un Cloudflare, vs en hosting tradicional? ¿Qué otras limitaciones puede tener Astro?

Matiz previo importante: Astro es híbrido, pero no es dinámico por defecto. De fábrica genera estático (SSG); el servidor solo entra en juego si añades un adapter (uno interesante a considerar el de Cloudflare, gratuito en muchos casos) y marcas rutas como server-rendered. Sin adapter, Astro es 100% estático y tiene todas las limitaciones de un sitio estático. Así que la cuestión es activar el renderizado en servidor.

Formularios propios vs externos, y el hosting/VPS tradicional

Puedes tener formularios propios en Astro, una vez tienes el adapter y SSR activo. El mecanismo son los endpoints de API (o server actions en Astro reciente): archivos en src/pages/ que exportan una función POST y se ejecutan en el servidor cuando el formulario se envía. Ahí recibes los datos, los validas y haces lo que necesites.

Pero ojo, maticemos ahora lo que significa ‘propio’:

• En Cloudflare Workers: el POST se ejecuta como código en el edge. Puedes procesar el formulario sin Formspree. Pero la gestión se complica: para enviarte el email con el contenido del formulario necesits un servicio de correo (Resend, un SMTP, la API de un proveedor…), porque un Worker no es un servidor de correo.
• En hosting/VPS tradicional con Node: Igual, pero el POST corre en tu proceso Node en lugar del edge. Mismo concepto, misma necesidad de una pieza de correo o base de datos para el paso final.

Conclusión: Puedes montar tu Astro en hosting tradicional, y tiene sentido si el proyecto es complejo. Para un formulario de contacto simple de una web de cliente, Formspree/Formsubmit (temas como Techlo Lite ya trae integrados) te ahorran montar el envío de correo tú mismo. Los endpoints propios compensan cuando el formulario hace algo más serio: guardar en base de datos, lógica condicional, integrarse con otra API, etc.

Otras limitaciones de Astro, y donde no conviene usarlo

• No es para apps de estado complejo. Astro brilla en sitios orientados a contenido. Si necesitas una aplicación con mucho estado compartido en cliente y navegación tipo app (un dashboard interactivo complejo, un editor tipo Figma), ahí un framework SPA-first como Next.js encaja mejor. Astro puede, pero remas contra su diseño.
• La interactividad rica exige islas, y las islas no comparten estado fácilmente. Cada isla es independiente; comunicar dos islas React entre sí (estado global compartido) es más trabajoso que en una SPA donde todo vive en el mismo árbol. Hay soluciones (nano stores), pero es fricción.
• El contenido estático requiere rebuild. Si una página es SSG, cambiar su contenido implica reconstruir y redesplegar. Sin un CMS headless conectado, no hay edición de contenido en vivo como en WordPress. (Esto ya lo tratamos: es el precio del modelo estático.)

Para el caso de una web de servicios orientadas a contenido, con algún formulario, estás justo en el centro de lo que Astro hace bien.

El patrón común para determinar cuando Astro no es la plataforma adecuada para nuestro proyecto es: aplicaciones vs sitios. Cuando más se parece a una aplicación y menos a un contenido que se lee, menos conviene. Y más concretamente, no conviene en:

• Dashboards / paneles de administración: datos en tiempo real, gráficos interactivos, filtros, tablas que se actualizan constantemente.
• Aplicaciones tipo herramienta: un editor (tipo Figma, Notion, Google Docs), una pizarra colaborativa, un cliente de correo web.
• Redes sociales / feeds en tiempo real: contenido que cambia por segundo, interacción constante del usuario.
• Apps con sesión intensiva y muchas vistas autenticadas: una banca online, un SaaS donde el usuario pasa horas dentro logueado operando.

¿Qué pasa con los e-commerce?

Sitios con productos y variaciones, carritos, … ¿Es adecuado un sitio hecho con Astro? la respuesta es depende. Astro encaja con matices.

• El catálogo (páginas de producto, listados, categorías, tallas, fotos, descripciones): esto es contenido. Es exactamente lo que Astro hace de maravilla, miles de páginas de producto generadas estáticamente, rápidas, cacheadas en el edge, óptimas para SEO. Un catálogo grande es un argumento a favor de Astro, no en contra.
• El carrito y el checkout (estado que cambia, «añadir a cesta», persistencia entre páginas, pasarela de pago): esto es interactividad con estado compartido. Aquí es donde aplicas islas: interactividad solo donde se necesita.

Y funciona bien porque las islas resuelven la parte dinámica y el 90% del sitio (el catálogo) sigue siendo estático veloz.

Sin embargo, el carrito es el ejemplo perfecto del problema de «las islas no comparten estado fácilmente». El carrito tiene que ser visible y coherente en toda la web.

En un e-commerce con solo Astro necesitas una capa deliberada de estado compartido — típicamente nano stores (recomendación oficial de Astro justo para esto) más persistencia en localStorage.

Dos formas de hacer e-commerce con Astro:

• Headless/integrado: Astro para el escaparate (catálogo estático veloz) + una plataforma que gestiona carrito, pagos e inventario (Shopify, Snipcart, Medusa). El carrito lo lleva el servicio externo. Es el enfoque más habitual y sensato — de hecho hay bundles de temas Astro específicos para Shopify headless. Tú te quedas con el rendimiento del escaparate y no reinventas la pasarela de pago.
• Todo propio con SSR: carrito con nano stores, checkout como endpoints server-rendered, pagos con Stripe, inventario en base de datos (D1 si es Cloudflare). Máximo control, máximo trabajo. Solo si tienes una razón fuerte para no usar una plataforma.

Un e-commerce a medida completo (enfoque 2) es un proyecto serio, y ahí la pregunta «¿Astro o algo más?» merece pensarse caso por caso.

Para un e-commerce pequeño, Astro + Snipcart (o similar) es una opción muy buena. Rápido, barato, poco mantenimiento.

Integraciones

🌐 [docs.astro.build#integrations] Working with integrations

Las integraciones añaden nuevas funcionalidades a tu proyecto con solo unas líneas de código. Puedes utilizar integraciones oficiales, creadas por la comunidad, o crear la tuya propia. Úsalas para:

• Desbloquear React, Vue y muchos otros frameworks UI con un renderer.
• Habilitar el renderizado a demanda con un adaptador SSR.
• Añade nuevas características y funcionalidades a tu proyecto, como la generación automática de sitemaps, o las herramientas MDX y Partytown.

Relacionado: 🌐 Directorio de integraciones

Astro frente a los generadores estáticos clásicos

Astro es coherente para alguien con una formación más usual/estándar (JS/HTML/CSS, más Markdown para el contenido).

Hugo está creado en el lenguaje Go, es el más rápido en build (binario único, compilación instantánea), pero es puramente SSG — no tiene SSR real. Puede simular dinamismo añadiendo funciones serverless/edge aparte, pero eso no es SSR del framework.

Por otra parte está Jekyll, con Ruby, el clásico de GitHub Pages, también puramente SSG, sin SSR nativo. Igual que Hugo, cualquier parte dinámica necesita una capa externa (JS en el cliente, API separada, etc.). Sin embargo, Jekyll sigue siendo perfectamente válido para su nicho (integración nativa con GitHub Pages sin CI/CD propio, blogs sencillos).

Algunas conclusiones de la comparativa

Astro es el más flexible de los tres comparados, si quieres mezclar contenido estático con partes dinámicas.

El agnosticismo de Astro en cuanto a UI, lo hace mucho más versátil que Hugo y Jekyll. Hugo, en contrapartida, utiliza su propio motor de plantillas basado en el lenguaje Go (Go Templates) y HTML.

Hugo: No necesitas obligatoriamente conocer Go, pero si estás decidiendo plataforma, la tecnología que subyace podría inclinar tu balanza hacia Astro.

Jekyll es la opción más limitada para proyectos que puedan crecer. Su cadena de Ruby es la más engorrosa de mantener.