Astro parte de una premisa que después de años de SPAs suena casi herética: por defecto, tu componente no envía JavaScript al navegador. Nada. Se renderiza a HTML en el build y ahí se queda, estático y rápido. La interactividad no es el estado natural de la página, es algo que tú pides explícitamente, componente a componente, con una directiva client:. Este blog está construido así, y entender la arquitectura de islas —cuándo hidratar y, sobre todo, cuándo no— es la diferencia entre una página que vuela y una que arrastra kilobytes de framework para animar un botón.
El modelo mental: HTML por defecto, JS bajo demanda
En una SPA clásica todo es JavaScript: el framework se monta entero en el cliente, hidrata todo el árbol y desde ahí gobierna la página. Es cómodo para el desarrollador y caro para el usuario, porque paga el coste de arrancar el framework aunque el 90% de la pantalla sea texto que nunca cambia.
Astro invierte la premisa. Renderiza tus componentes a HTML en el servidor o en el build, y por defecto descarta el JavaScript que los generó. Lo que llega al navegador es HTML plano que pinta al instante. Las "islas" son las zonas concretas que sí necesitan vida propia —un carrusel, un formulario con validación, un menú desplegable— rodeadas de un mar de HTML estático que no cuesta nada. Cada isla se hidrata de forma independiente; el resto de la página ni se entera.
Las directivas client: son la decisión, no un detalle
La palanca es la directiva que le pones al componente al usarlo. Cada una describe cuándo se hidrata esa isla, y elegir bien es donde está el rendimiento:
---
import Carousel from '../components/Carousel.jsx';
import NewsletterForm from '../components/NewsletterForm.jsx';
import HeavyChart from '../components/HeavyChart.jsx';
---
<!-- Se hidrata en cuanto carga la página: para lo que se ve arriba -->
<Carousel client:load />
<!-- Se hidrata cuando entra en el viewport: para lo que está más abajo -->
<HeavyChart client:visible />
<!-- Se hidrata cuando el navegador está ocioso: para lo no urgente -->
<NewsletterForm client:idle />
client:load hidrata de inmediato: úsalo solo para lo que es interactivo desde el primer pixel visible. client:idle espera a que el hilo principal respire. client:visible es mi favorita: no gasta un byte de JavaScript hasta que el componente entra en pantalla, ideal para todo lo que vive por debajo del fold. La directiva no es un adorno de sintaxis: es literalmente la política de carga de cada isla, y ponerlas a la ligera es cómo se cuela JavaScript que el usuario no necesita.
Cuándo NO hidratar (que es casi siempre)
El error más común de quien llega desde React es tratar cada componente como si necesitara estado. No lo necesita. Una tarjeta, un encabezado, una lista de posts, un pie de página: todo eso es HTML que se pinta una vez y no vuelve a cambiar. Si no hay evento, no hay estado y no hay interacción, no hay isla. Se queda como componente estático de Astro y envía cero JavaScript.
La pregunta que me hago ante cada componente no es "¿puede ser interactivo?", sino "¿tiene que responder a algo del usuario en el cliente?". Un botón que solo es un enlace no es una isla, es una etiqueta <a>. Un acordeón se puede hacer con <details> y <summary> nativos sin una línea de JS. Cuanto más empujo la interactividad hacia HTML y CSS nativos, menos islas necesito y más ligera queda la página.
💡 En Astro, cada
client:que escribes es JavaScript que el usuario descarga. La mejor optimización no es hidratar más rápido, es no hidratar.
Las islas no comparten estado, y eso es a propósito
Aquí está el trade-off que hay que tener claro antes de casarse con el modelo. Cada isla es un componente aislado: se hidrata sola y no comparte estado con las demás por arte de magia. Si vengo de una SPA donde un store global lo conecta todo, esto se siente como una limitación. Dos islas que necesitan hablar entre sí no lo hacen a través de props, porque son árboles independientes montados por separado.
La solución existe —eventos del navegador, nanostores compartidos, señales— pero es fricción real, y esa fricción es la señal de que quizá estás usando la herramienta a contrapelo. Si tu página es básicamente una aplicación con estado muy entrelazado, muchas partes hablando entre sí constantemente, Astro te va a pedir gimnasia para algo que un framework de SPA te da gratis. Ahí no fuerzo Astro: elijo la herramienta adecuada.
Por qué elegí este modelo igualmente
Astro brilla cuando el contenido manda y la interactividad es puntual: blogs, sitios de marketing, documentación, portfolios, e-commerce con islas de producto. Es exactamente la forma de la mayoría de la web, y de este sitio. Acepto la fricción de coordinar islas a cambio de que, por defecto, cada página nazca sin peso, y que sea yo quien decide y justifica cada kilobyte de JavaScript que añado.
Ese cambio de default lo es todo. En una SPA el JavaScript es la norma y quitarlo cuesta trabajo; en Astro el JavaScript es la excepción y añadirlo es una decisión consciente. Prefiero un sistema donde lo barato es lo fácil y lo caro requiere que yo lo pida a propósito. Esa inversión de la carga por defecto es, para el tipo de webs que construyo, la mejor decisión de rendimiento que puedo tomar sin optimizar una sola línea.
