Astro: el framework que decidió que el JavaScript era opcional

El punto de partida

Un framework como Next.js o Nuxt parte del supuesto de que estás construyendo una aplicación: hay estado, interacción, rutas dinámicas, sesión de usuario. Todo el JavaScript del framework viaja al navegador porque, tarde o temprano, se va a necesitar.

El problema es que la mayoría de los sitios que se construyen con esas herramientas no son aplicaciones. Son blogs, landings, sitios institucionales, documentación, catálogos. Contenido que se lee. Y ahí estás pagando cientos de kilobytes de runtime para renderizar texto que podría ser HTML plano.

Astro invierte el supuesto: asume que estás construyendo un sitio de contenido y que la interactividad es la excepción, no la regla. Compila todo a HTML estático y elimina el JavaScript que no se usa. Un blog hecho en Astro puede llegar al navegador con literalmente cero bytes de JS.

La arquitectura de islas

Es el concepto central y vale entenderlo bien.

En lugar de hidratar toda la página, Astro renderiza HTML estático y permite marcar componentes puntuales como «islas» interactivas. Cada isla carga su JavaScript de forma independiente y solo cuando corresponde.

astro

---
import Header from '../components/Header.astro';
import Carrusel from '../components/Carrusel.jsx';
import Calculadora from '../components/Calculadora.jsx';
---

<Header />

<Carrusel client:load />
<Calculadora client:visible />

Las directivas controlan cuándo se activa cada isla:

• client:load — hidrata apenas carga la página.
• client:idle — espera a que el navegador esté ocioso.
• client:visible — hidrata recién cuando el componente entra en pantalla.
• client:media — solo si se cumple una media query (ideal para menús que difieren en mobile).
• client:only — se renderiza únicamente en el cliente.

El Header del ejemplo no lleva directiva, así que es HTML puro: no cuesta nada. La calculadora, que está al pie de la página, ni siquiera descarga su JavaScript hasta que el visitante llega ahí. Es una diferencia enorme en el Largest Contentful Paint de un sitio con contenido largo.

Agnóstico de framework

Otro punto que sorprende a quien viene de React: en Astro las islas pueden estar escritas en React, Vue, Svelte, Solid o Preact, en el mismo proyecto. Se instalan como integraciones y conviven sin problema.

En la práctica esto significa que podés reutilizar un componente que ya tenías en React sin migrarlo, y escribir el resto del sitio en .astro, que es básicamente HTML con frontmatter y sintaxis tipo JSX. Si sabés HTML y algo de JS, la curva es de un par de horas.

Colecciones de contenido

Para blogs y catálogos, esta es la funcionalidad que más trabajo ahorra. Definís un esquema con Zod y Astro te valida cada archivo Markdown en tiempo de build:

ts

import { defineCollection, z } from 'astro:content';

const notas = defineCollection({
  schema: z.object({
    titulo: z.string(),
    copete: z.string(),
    fecha: z.date(),
    keywords: z.array(z.string()),
    portada: z.string().optional(),
  }),
});

export const collections = { notas };

Si te olvidás la fecha en una nota, el build falla con un mensaje claro en lugar de publicar una página rota. Y todo el contenido queda tipado, así que el editor te autocompleta los campos.

Dónde está Astro hoy

La versión 7 salió el 22 de junio de 2026 y el foco fue casi todo rendimiento de build: compilador reescrito en Rust, migración a Vite 8 con Rolldown y un nuevo parser de Markdown, también en Rust. Para proyectos grandes, con cientos de páginas de contenido, la diferencia en tiempos de compilación es la mejora más visible. Requiere Node 22 como mínimo, así que conviene revisar el entorno antes de actualizar.

También sumó detección de agentes de IA y mejoras de caché en el ruteo, dos temas que ganaron peso este año. Y desde la versión 6 el framework tiene respaldo corporativo de Cloudflare, lo que despeja bastante la duda razonable de «¿esto va a seguir existiendo en tres años?».

Astro vs. las alternativas

Contra WordPress: Astro gana en velocidad, seguridad (no hay base de datos ni panel expuesto) y costo de hosting (un sitio estático se sirve gratis o casi). Pierde en gestión de contenido: si el cliente necesita cargar entradas solo desde un panel, sin tocar archivos, necesitás sumarle un CMS headless. Existe la combinación WordPress como backend y Astro como frontend, que resuelve las dos cosas, pero es más infraestructura para mantener.

Contra Next.js: para una aplicación con sesión, dashboard y estado compartido, Next sigue siendo la elección correcta. Para un sitio de contenido, Next es una herramienta desproporcionada.

Contra HTML y CSS a mano: Astro te da componentes, layouts, colecciones tipadas y optimización de imágenes sin renunciar al resultado estático. Es lo que uno haría a mano, pero organizado.

Cuándo conviene

Sí:

• Blogs, sitios institucionales, landings, documentación, portfolios.
• Catálogos que no necesitan carrito.
• Proyectos donde el SEO y la velocidad de carga son el objetivo principal.
• Frontends que consumen una API propia y son mayormente de lectura.

No, o con reservas:

• Aplicaciones con mucho estado compartido entre pantallas.
• Sitios donde el cliente necesita autonomía total de edición y no querés sumar un CMS.
• E-commerce complejo con stock en tiempo real, variantes y checkout propio: es posible, pero WooCommerce o Shopify te ahorran meses.

En resumen

Astro no compite por ser el framework más potente, sino por ser el más proporcionado a lo que la mayoría de los sitios necesita. La pregunta que resuelve es simple: si la página es contenido que se lee, ¿por qué le estás mandando al visitante un runtime completo de JavaScript?

Para un desarrollador que ya trabaja con React o con WordPress, la inversión de aprenderlo es baja y el retorno se nota en la primera medición de PageSpeed. Vale la pena tenerlo en el toolkit aunque no sea la herramienta de todos los proyectos.