Astro

¿Qué es Astro?

Astro es un framework web centrado en el contenido construido bajo una premisa simple: la mayoría de las páginas no necesitan mucho JavaScript. Por defecto, renderiza las páginas a HTML, no envía JavaScript al cliente a menos que lo solicites y te permite añadir componentes interactivos solo donde realmente son necesarios.

Este diseño hace que Astro sea excepcionalmente bueno para el tipo de sitios que conforman gran parte de la web: blogs, documentación, páginas de marketing, portafolios y productos con mucho contenido. No es que sea anti-JavaScript, sino que apuesta por la moderación. Obtienes la interactividad que necesitas y nada más.

Componentes .astro

Un componente de Astro es un archivo que contiene un script de frontmatter, una plantilla y estilos opcionales con alcance local (scoped).

---
// src/components/Card.astro
interface Props {
  title: string;
  href: string;
}

const { title, href } = Astro.props;
---

<a class="card" href={href}>
  <h3>{title}</h3>
  <slot />
</a>

<style>
  .card {
    display: block;
    border-radius: 1rem;
    padding: 1.5rem;
  }
</style>

El frontmatter se ejecuta en el servidor durante el tiempo de compilación (build time) o por cada solicitud. La plantilla es HTML con expresiones similares a JSX, y el <slot /> permite que un componente padre pase elementos hijos. Por defecto, los estilos están limitados al alcance del componente. Debido a que el componente se ejecuta en el servidor, puedes realizar consultas a bases de datos, leer archivos y llamar a APIs directamente en el frontmatter.

Enrutamiento basado en archivos

Los archivos en src/pages se convierten en rutas, y los segmentos dinámicos utilizan corchetes.

src/pages/
├── index.astro            # /
├── about.astro            # /about
├── blog/
│   ├── index.astro        # /blog
│   └── [slug].astro       # /blog/:slug
└── rss.xml.js             # /rss.xml

Para las rutas dinámicas, exportas getStaticPaths para declarar qué páginas construir, o utilizas SSR para renderizar bajo demanda.

Colecciones de contenido

Las colecciones de contenido son la respuesta de Astro al contenido estructurado. Defines un esquema y cada entrada de markdown o JSON se valida en el momento de la compilación (build time).

// src/content.config.ts
import { defineCollection, z } from "astro:content";

const blog = defineCollection({
  schema: z.object({
    title: z.string(),
    publishedAt: z.coerce.date(),
    tags: z.array(z.string()).default([]),
  }),
});

export const collections = { blog };

---
// src/pages/blog/index.astro
import { getCollection } from "astro:content";

const posts = (await getCollection("blog"))
  .sort((a, b) => b.data.publishedAt.valueOf() - a.data.publishedAt.valueOf());
---

<ul>
  {posts.map((post) => (
    <li>
      <a href={`/blog/${post.id}`}>{post.data.title}</a>
    </li>
  ))}
</ul>

Obtienes seguridad de tipos, validación y una forma limpia de consultar contenido sin necesidad de una base de datos. Para un sitio con cientos de publicaciones o páginas de documentación, esto representa una mejora significativa en la calidad de vida del desarrollo.

La arquitectura de islas

Esta es la característica definitoria de Astro. Una página es HTML estático, y cualquier componente interactivo es una isla que se hidrata de forma independiente. Tú controlas cuándo se carga cada isla mediante una directiva de cliente.

---
import Counter from "../components/Counter.jsx";
import Comments from "../components/Comments.jsx";
---

<Counter client:load />
<Comments client:visible />

Las directivas son:

• client:load se hidrata inmediatamente; ideal para interactividad crítica en la parte superior de la página (above-the-fold).
• client:idle se hidrata una vez que el navegador esté libre.
• client:visible se hidrata cuando el componente entra en el campo de visión al hacer scroll.
• client:only omite el renderizado en el servidor y se renderiza únicamente en el navegador.
• client:media se hidrata cuando coincide una media query.

Elegir la directiva menos agresiva que cumpla la función mantiene la página rápida. La mayoría de las páginas de contenido no necesitan ninguna.

Trae tu propia librería de UI

Astro puede renderizar componentes de React, Vue, Svelte, Solid y Preact — en el mismo proyecto.

---
import ReactChart from "../components/Chart.jsx";
import VueForm from "../components/Form.vue";
---

<ReactChart client:load data={data} />
<VueForm client:visible />

Cada framework es una integración opcional. Puedes usar React para una isla y Svelte para otra, o prescindir totalmente de los frameworks. Esa flexibilidad significa que nunca estarás limitado y podrás adoptar una librería solo donde realmente aporte valor.

SSR y adaptadores

Astro es estático por defecto, pero puede renderizar bajo demanda. Añade un adaptador para tu plataforma y configura las rutas para que utilicen el renderizado en el servidor.

// astro.config.mjs
import { defineConfig } from "astro/config";
import node from "@astrojs/node";

export default defineConfig({
  output: "server",
  adapter: node({ mode: "standalone" }),
});

Los endpoints de la API residen en src/pages/api y exportan métodos HTTP, mientras que las server islands te permiten renderizar fragmentos dinámicos dentro de páginas que, de otro modo, serían estáticas. Esto hace que Astro sea ideal para sitios híbridos: un blog estático con un dashboard dinámico, o un sitio de marketing con secciones personalizadas.

Mejores prácticas

• Prioriza los componentes .astro; añade componentes de framework solo para la interactividad.
• Utiliza la directiva de cliente menos agresiva que funcione.
• Mantén el contenido en colecciones con un esquema en lugar de markdown de formato libre.
• Define el alcance de los estilos con bloques <style> de componentes o con la herramienta de CSS elegida.
• Renderiza las páginas estáticas en tiempo de compilación y reserva el SSR para las rutas dinámicas.
• Utiliza layouts para las estructuras compartidas y los metadatos.
• Optimiza las imágenes con los componentes de imagen integrados.

Errores comunes

• Añadir client:load en todas partes y perder el beneficio de zero-JavaScript.
• Recurrir a un framework de UI cuando un componente .astro sería suficiente.
• Olvidar definir un esquema y perder la seguridad de tipos en las colecciones.
• Asumir que Astro no puede crear aplicaciones dinámicas e ignorar el SSR.
• Mezclar demasiados frameworks de UI e inflar el proyecto sin motivo.
• Usar fetching en el lado del cliente para contenido que podría renderizarse en el momento de la compilación.

Próximos pasos

Astro es la opción pragmática para sitios con mucho contenido que aún requieren puntos de interactividad. Refuerza tus conocimientos de HTML y CSS, y luego compara este modelo con Next.js, Nuxt y SvelteKit. Después, construye un blog pequeño con una content collection y una isla interactiva para analizar las ventajas y desventajas por ti mismo.