Tag: Astro

  • Astro v7: novedades clave y cómo crear tu landing desde cero

    Astro v7: novedades clave y cómo crear tu landing desde cero

    Un developer me escribió hace unas semanas. Tenía una landing page para un producto que estaba a punto de lanzar. La había montado con Next.js porque “era lo que conocía”. El tiempo de build era de 4 minutos. El bundle pesaba más de lo que debería. Y lo único que necesitaba era una página estática con una sección hero, tres features y un formulario de contacto.

    Next.js para eso es como usar un martillo neumático para clavar un cuadro.

    La respuesta que le di fue una sola palabra: Astro. Y ahora, con Astro v7, esa respuesta es más sólida que nunca.


    Qué es Astro, por si llevas tiempo mirando para otro lado

    Astro es un framework de generación de sitios estáticos que tiene una idea central brillante: envía cero JavaScript al cliente por defecto. Solo envía HTML y CSS. Si necesitas interactividad en algún componente concreto, la añades con lo que quieras: React, Vue, Svelte, Lit — Astro lo llama “islands”.

    Para landings, blogs, documentación y cualquier sitio orientado al contenido, no hay nada más rápido ni más sencillo de mantener.

    Astro v7 lleva esa idea más lejos que nunca. Y los números lo avalan.


    Las novedades reales de Astro v7

    Astro v7 es la séptima versión mayor del framework, lanzada en 2026, que introduce un compilador reescrito en Rust, Vite 8 con Rolldown y Route Caching estable como cambios principales. Es la versión con el mayor salto de rendimiento desde el lanzamiento del framework.

    El compilador se reescribió en Rust — y se nota

    La parte más importante de esta versión no es una nueva API. Es que el compilador de .astro pasó de estar escrito en Go a estar escrito en Rust.

    El resultado: builds entre un 15% y un 61% más rápidos en benchmarks reales. El sitio de documentación oficial de Astro pasó de tardar 114 segundos en construirse a 73. El propio astro.build bajó de 62 segundos a 24 (datos oficiales del blog de Astro).

    Eso es el tipo de mejora que no se consigue ajustando configuraciones. Es un cambio de arquitectura.

    El tradeoff: el compilador Rust es más estricto con HTML inválido. Antes, si dejabas una etiqueta sin cerrar, Astro la corregía silenciosamente. Ahora lanza un error. Lo cual, seamos honestos, es el comportamiento correcto.

    Vite 8 con Rolldown — el bundler en Rust también

    Astro v7 actualiza a Vite 8, que trae Rolldown: un bundler escrito en Rust que reemplaza tanto a esbuild como a Rollup con una sola herramienta unificada. En benchmarks, es 10-30 veces más rápido que Rollup.

    La compatibilidad con la API de plugins de Rollup y Vite se mantiene. Si tienes plugins existentes, seguirán funcionando.

    Nuevo procesador Markdown: Sätteri

    El pipeline de Markdown ha cambiado por completo. El procesador anterior basado en unified, remark y rehype ha sido reemplazado por Sätteri, un procesador escrito también en Rust.

    Sätteri incluye de serie: GitHub Flavored Markdown, tipografía inteligente, IDs de encabezados, directivas, matemáticas y frontmatter. Sin configuración adicional.

    Si tenías plugins personalizados de remark o rehype, puedes volver al pipeline anterior instalando @astrojs/markdown-remark y configurándolo explícitamente. No pierdes nada — solo dejas de tenerlo por defecto.

    Route Caching ahora es estable

    El sistema de caché de rutas, que estaba en experimental, ya es parte de la API estable. Puedes controlar el caché de cada respuesta con una API agnóstica a la plataforma:

    // En cualquier página .astro o endpoint
    Astro.cache.set({
      maxAge: 120,     // 2 minutos en caché de cliente/servidor
      swr: 60,         // 1 minuto de revalidación en background
      tags: ['products']
    });

    Y cuando necesitas invalidar:

    await cache.invalidate({ tags: ['products'] });

    Para Netlify, Vercel y Cloudflare hay CDN cache providers experimentales que traducen estas directivas a la capa edge de cada plataforma.

    Advanced Routing — control total del pipeline

    Astro v7 introduce un archivo src/fetch.ts que te da acceso completo al pipeline de solicitudes, antes de que Astro las procese. Compatible con Hono para middleware:

    // src/fetch.ts
    import { astro } from 'astro/fetch';
    
    

    export default { fetch(request: Request) { const url = new URL(request.url);

    // Intercepta rutas /api antes de que lleguen a Astro if (url.pathname.startsWith('/api')) { return fetch('https://mi-backend.com' + url.pathname, request); }

    return astro(request); } }

    Si ya tienes un src/fetch.ts propio en tu proyecto, Astro v7 lo detectará y te pedirá que lo renombres o que desactives esta feature.

    Modo para agentes IA

    Esto es interesante si construyes herramientas con IA o trabajas con Claude Code, Cursor u otros coding agents. Astro v7 detecta automáticamente cuando está corriendo dentro de un agente y activa dos comportamientos:

    1. Inicia el servidor de desarrollo en modo background con astro dev --background
    2. Cambia los logs a formato JSON estructurado para que el agente los pueda parsear
    # Arranque idempotente — no lanza otro servidor si ya hay uno corriendo
    astro dev --background
    
    

    # Estado del servidor astro dev status

    # Logs en JSON astro dev --json


    Astro v6 vs v7 — qué cambió exactamente

    Área Astro v6 Astro v7
    Compilador .astro Go Rust (15-61% más rápido)
    Bundler Vite 7 + Rollup Vite 8 + Rolldown (Rust)
    Procesador Markdown unified / remark / rehype Sätteri (Rust, GFM incluido)
    Route Caching Experimental Estable (Astro.cache.set)
    Routing avanzado No disponible src/fetch.ts estable
    Modo agente IA No disponible astro dev --background + logs JSON
    HTML inválido Corregido silenciosamente Error de compilación (más estricto)
    @astrojs/db Disponible Eliminado → migrar a node:sqlite

    Cómo crear tu landing con Astro v7 — paso a paso

    Paso 1 — Instalación

    npm create astro@latest mi-landing

    El wizard te preguntará si quieres una plantilla vacía, con blog, o con un starter. Para una landing, elige “Empty” o “A basic, minimal starter”.

    cd mi-landing
    npm run dev

    Tu servidor de desarrollo estará en http://localhost:4321.

    Paso 2 — Estructura del proyecto

    mi-landing/
    ├── public/
    │   └── favicon.svg
    ├── src/
    │   ├── components/
    │   │   ├── Header.astro
    │   │   ├── Hero.astro
    │   │   ├── Features.astro
    │   │   └── Footer.astro
    │   ├── layouts/
    │   │   └── BaseLayout.astro
    │   └── pages/
    │       └── index.astro
    ├── astro.config.mjs
    └── package.json

    Paso 3 — El layout base

    ---
    // src/layouts/BaseLayout.astro
    interface Props {
      title: string;
      description: string;
    }
    
    

    const { title, description } = Astro.props;


    <!doctype html> <html lang="es"> <head> <meta charset="UTF-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <meta name="description" content={description} /> <title>{title}</title> </head> <body> <slot /> </body> </html>

    Paso 4 — Los componentes de la landing

    ---
    // src/components/Hero.astro
    interface Props {
      headline: string;
      subheadline: string;
      ctaText: string;
      ctaHref: string;
    }
    
    

    const { headline, subheadline, ctaText, ctaHref } = Astro.props;


    <section class="hero"> <h1>{headline}</h1> <p>{subheadline}</p> <a href={ctaHref} class="cta-btn">{ctaText}</a> </section>

    <style> .hero { display: flex; flex-direction: column; align-items: center; padding: 4rem 1rem; text-align: center; gap: 1.5rem; }

    h1 { font-size: clamp(2rem, 5vw, 3.5rem); font-weight: 800; line-height: 1.1; }

    .cta-btn { display: inline-block; padding: 0.9rem 2rem; background: #7c3aed; color: white; text-decoration: none; border-radius: 0.5rem; font-weight: 600; transition: opacity 0.2s; }

    .cta-btn:hover { opacity: 0.85; } </style>

    ---
    // src/components/Features.astro
    const features = [
      {
        icon: "⚡",
        title: "Velocidad real",
        description: "HTML puro en el cliente. Sin JavaScript innecesario."
      },
      {
        icon: "🧩",
        title: "Componentes modulares",
        description: "Divide la UI en piezas reutilizables con props tipadas."
      },
      {
        icon: "🚀",
        title: "Deploy en segundos",
        description: "Estático por defecto. Netlify, Vercel o Cloudflare Pages."
      }
    ];
    

    <section class="features"> <h2>Por qué esto funciona</h2> <ul class="features-grid"> {features.map((feature) => ( <li> <span class="icon">{feature.icon}</span> <h3>{feature.title}</h3> <p>{feature.description}</p> </li> ))} </ul> </section>

    <style> .features { padding: 4rem 1rem; max-width: 900px; margin: 0 auto; }

    h2 { text-align: center; font-size: 2rem; margin-bottom: 2.5rem; }

    .features-grid { display: grid; grid-template-columns: repeat(auto-fit, minmax(240px, 1fr)); gap: 2rem; list-style: none; padding: 0; }

    .icon { font-size: 2rem; display: block; margin-bottom: 0.75rem; }

    h3 { font-size: 1.1rem; margin-bottom: 0.5rem; } </style>

    Paso 5 — La página principal que lo une todo

    ---
    // src/pages/index.astro
    import BaseLayout from '../layouts/BaseLayout.astro';
    import Hero from '../components/Hero.astro';
    import Features from '../components/Features.astro';
    

    <BaseLayout title="Mi Producto — La forma más rápida de hacer X" description="Descripción de 160 caracteres para el SEO." > <Hero headline="Resuelve X sin Y" subheadline="La frase que convierte la curiosidad en intención de compra." ctaText="Empieza gratis" ctaHref="#registro" /> <Features /> </BaseLayout>

    Paso 6 — Build y deploy

    # Build de producción
    npm run build
    
    

    # Preview local del build npm run preview

    El output es estático por defecto: la carpeta dist/ contiene HTML, CSS y los assets optimizados. Sube esa carpeta a Netlify, Vercel o Cloudflare Pages y estás listo.


    Los breaking changes que tienes que revisar si migras desde v6

    Si ya usas Astro y estás actualizando, el comando oficial es:

    npx @astrojs/upgrade

    Pero antes de ejecutarlo, ten en cuenta estos cuatro puntos:

    1. Etiquetas HTML sin cerrar ahora son errores. El compilador Rust no las corrige. Revisa tus componentes .astro buscando

    ,

  • o cualquier etiqueta no-void sin su cierre correspondiente.

    2. @astrojs/db ha sido eliminado. Si lo usabas, migra a node:sqlite (disponible desde Node.js 22.5.0), Drizzle ORM, Turso o cualquier alternativa SQL moderna.

    3. Los eventos de astro:transitions cambiaron. TRANSITION_BEFORE_PREPARATION y similares desaparecen. Sus equivalentes son strings directos como 'astro:after-swap'.

    4. Si tenías features en experimental, sácalas de ahí. queuedRendering, advancedRouting, cache y logger ya son estables. Muévelos al nivel raíz de astro.config.mjs.


    Por qué Astro v7 importa ahora mismo

    Astro es la respuesta correcta para landings y sites de documentación. No porque React sea malo, sino porque la herramienta correcta para contenido estático no es un SPA. Si estás construyendo productos con IA y quieres entender cómo encaja el frontend en ese stack, el post sobre el stack IA agéntica en 2026 te da el mapa completo de herramientas.

    El patrón que más se repite en los proyectos con IA que veo últimamente: alguien genera una landing con un agente y lo hace con el stack que “siempre ha usado”. El resultado: un bundle de React para servir contenido estático.

    Astro es la respuesta correcta para ese caso de uso. No porque React sea malo, sino porque la herramienta correcta para una landing o un site de documentación no es un SPA.

    El hecho de que Astro v7 ahora detecte agentes IA automáticamente no es un detalle menor — es una señal de hacia dónde va el ecosistema. Si usas Claude Code o Cursor para generar código, el post sobre cómo funciona el agentic loop explica el mecanismo detrás de esa integración.

    En el curso de Construye con IA trabajamos exactamente este tipo de decisiones: cuándo elegir Astro, cuándo Next.js tiene sentido, y cómo pasar de una idea a un producto sin arrastrar deuda técnica desde el primer día.

    Con el enfoque de Spec-Driven Development, diseñar la arquitectura de este tipo de landing antes de escribir la primera línea de código es lo que separa una landing que escala de una que se convierte en un problema de mantenimiento en seis meses.


    FAQ

    ¿Astro v7 es compatible con React, Vue o Svelte?

    Sí. Astro sigue siendo agnóstico al framework de UI. Puedes usar componentes de React, Vue, Svelte, Solid o cualquier otro framework compatible mediante el sistema de integraciones. Lo que cambia es que Astro no envía el runtime de esos frameworks al cliente a menos que marques explícitamente un componente con una directiva client:*.

    ¿Necesito migrar a Sätteri si tengo plugins de remark personalizados?

    No es obligatorio. Puedes instalar @astrojs/markdown-remark y configurar markdown: { processor: unified() } en tu astro.config.mjs para mantener el pipeline anterior. Sätteri es el nuevo default, pero el viejo pipeline sigue disponible.

    ¿Puedo usar Astro v7 para sitios con contenido dinámico, no solo estático?

    Sí. Astro soporta SSR (Server-Side Rendering) con adaptadores para Node.js, Netlify, Vercel y Cloudflare Workers. Con el nuevo Advanced Routing y src/fetch.ts tienes control total sobre el pipeline de solicitudes. Para contenido que cambia con frecuencia, el nuevo sistema de Route Caching con invalidación por tags es especialmente útil.

    ¿Cuánto cuesta migrar un proyecto de Astro v5 o v6 a v7?

    Depende del proyecto, pero el comando npx @astrojs/upgrade automatiza la mayor parte. Los cambios manuales más comunes son: cerrar etiquetas HTML que el compilador anterior perdonaba, eliminar @astrojs/db si lo usabas, y sacar las features que estaban en experimental al nivel raíz de la configuración. En un proyecto mediano, una tarde es suficiente.

    ¿Astro v7 es una buena opción para documentación técnica?

    Es probablemente la mejor opción disponible. El procesador Sätteri maneja GFM, directivas y matemáticas de serie. El sistema de content collections te permite estructurar MDX como si fuera una base de datos. Y los builds son ahora significativamente más rápidos, lo que importa cuando tienes cientos de páginas de documentación. No en vano, el propio sitio de documentación de Astro corre sobre Astro.


    Si quieres ver cómo integramos herramientas como Astro en un flujo de trabajo completo con IA — desde el spec hasta el deploy — en Dominicode Labs tenemos proyectos activos donde exploramos exactamente ese proceso.

    Y si prefieres empezar con vídeo, en el canal de YouTube de Dominicode hay contenido regular sobre desarrollo con IA, Angular, TypeScript y herramientas de producción.


    Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.

  • Mejoras en Astro 6.2: Server Islands y Astro Actions

    Lo nuevo de Astro 6.2 y porque lo tienes que probar

    Tiempo estimado de lectura: 4 min

    • Rendimiento y entrega de HTML: Server Islands y mejoras que reducen el TTFB.
    • Ergonomía y seguridad: Astro Actions introduce RPC tipado con validación integrada.
    • Contenido externo en build: Content Layer trata APIs, CMS y bases como ciudadanos de primera clase.
    • Developer experience: arranques y HMR más rápidos en proyectos grandes o monorepos.

    Resumen y análisis técnico de las mejoras introducidas en Astro 6.2, con ejemplos prácticos y recomendaciones para equipos que priorizan rendimiento, tipado y manejo de contenido externo.

    Resumen rápido (lectores con prisa)

    Qué es: Actualización de Astro que mejora renderizado diferido, añade RPC tipado para mutaciones y consolida una capa de contenido para fuentes externas.

    Cuándo usarlo: Para sitios estáticos con zonas personalizadas, e-commerce y documentación donde SEO y Core Web Vitals importan.

    Por qué importa: Reduce JavaScript por defecto, mejora TTFB y convierte errores runtime en fallos de compilación mediante tipado.

    Cómo funciona (alto nivel): Server Islands difiere componentes dinámicos; Astro Actions expone funciones servidor/cliente tipadas; Content Layer mapea fuentes externas a colecciones validadas en build.

    Lo nuevo de Astro 6.2 y por qué lo tienes que probar: cambios clave

    Astro 6.2 no es una mejora cosmética. Afecta tres ejes que importan en producción: tiempo de entrega de HTML, seguridad y ergonomía del desarrollo, y cómo incorporas datos externos al proceso de build.

    • Mejoras en el servidor de desarrollo: resolución de módulos más rápida, arranques y HMR optimizados. Menos fricción en repos grandes o monorepos.
    • Server Islands estabilizadas: capacidad de diferir componentes server-side sin bloquear el TTFB.
    • Astro Actions: RPC tipado para mutaciones y formularios, con validación integrada.
    • Content Layer API: conectores para CMS, bases de datos o Notion, con validación y caching en build.

    Fuente oficial y changelog: astro.build/blog/astro-620/

    Server Islands: reducir TTFB sin perder personalización

    El patrón Server Islands en 6.2 se vuelve practicable en entornos de producción. La idea es simple y poderosa: renderizas la estructura estática y cacheable en el CDN; los componentes dinámicos se resuelven de forma diferida e independiente.

    Ejemplo mínimo

    ---
    import UserAvatar from '../components/UserAvatar.astro';
    ---
    
    Cargando avatar…

    Consecuencia práctica: el TTFB de la página no depende de la latencia de la consulta más lenta. Para páginas con contenido mayoritariamente estático y pequeñas zonas de personalización (e-commerce, landing pages personalizadas), la ganancia es directa y repetible.

    Documentación Server Islands: docs.astro.build/en/guides/server-islands/

    Astro Actions: menos endpoints, menos errores tipográficos

    Astro Actions introduce una abstracción RPC que reduce boilerplate y errores de sincronía entre cliente y servidor. Defines la acción en el servidor con validación (Zod) y la llamas desde el formulario como si fuera una función.

    Servidor

    import { defineAction } from 'astro:actions';
    import { z } from 'astro:schema';
    
    export const server = {
      subscribe: defineAction({
        input: z.object({ email: z.string().email() }),
        handler: async ({ email }) => {
          await db.insert({ email });
          return { success: true };
        },
      }),
    };
    

    Cliente (form)

    <form method="POST" action={actions.subscribe}>
      <input type="email" name="email" required />
      <button type="submit">Suscribirse</button>
    </form>
    

    Ventaja: si cambias el esquema, la compilación en el cliente falla. Eso convierte errores que antes aparecían en runtime en fallos de compilación, lo que mejora la confiabilidad y acelera el feedback loop.

    Guía de Actions: docs.astro.build/en/guides/actions/

    Content Layer API: datos externos como primera clase

    La Content Layer API en 6.2 permite tratar datos externos (CMS headless, Notion, bases SQL, APIs) como si fueran archivos locales durante el build. Tienes validación tipada, relaciones entre colecciones y caché inteligente.

    Arquitectónicamente significa desacoplar la fuente de contenido de la presentación sin perder seguridad en tipos y esquemas. Para equipos que manejan contenido editorial, marketing o documentación técnica, esto reduce fricción entre productores de contenido y desarrolladores.

    Docs Content Layer: docs.astro.build/en/guides/content-collections/

    ¿Cuándo adoptar Astro 6.2 y cuándo no?

    Adóptalo si:

    • Construyes sitios donde el SEO y Core Web Vitals son críticos (e-commerce, medios, docs).
    • Quieres reducir JavaScript enviado por defecto y solo hidratar lo necesario.
    • Necesitas un puente entre contenido diverso (Notion, CMS) y renderizado tipado en build.

    No es la mejor elección si:

    • Construyes aplicaciones con estado complejo y alta interactividad en cliente (editores colaborativos, apps en tiempo real intensivas).
    • Tu equipo necesita mantener un único modelo mental SPA sin fragmentar la responsabilidad entre server y client.

    Integración práctica: checklist rápido

    1. Prueba en un proyecto piloto: migra una página de marketing o un listado de productos.
    2. Instrumenta Server Islands en componentes con latencia (perfilado DB, llamadas externas).
    3. Usa Astro Actions en formularios y mutaciones sencillas para comprobar el feedback tipado.
    4. Conecta una fuente externa con Content Layer y valida el cacheo y el tiempo de build.
    5. Añade validaciones en CI para evitar regressiones en las APIs internas.

    Conclusión técnica

    Astro 6.2 madura un enfoque: menos JavaScript por defecto, más control en el servidor, y herramientas para que la mutación de datos y el contenido externo no sean fuentes de fragilidad. No es una panacea, pero sí una palanca técnica que reduce costes operativos y mejora métricas críticas. Pruébalo en un caso real y decide con datos, no con intuiciones. Repositorio y más referencias: github.com/withastro/astro

    FAQ

    Respuesta: Mejora la entrega de HTML (TTFB), introduce RPC tipado para mutaciones (Astro Actions) y consolida una Content Layer para tratar fuentes externas con validación y cache en build.

    Respuesta: Separando el HTML estático (entregable y cacheable) de los componentes dinámicos que se hidratan o resuelven de forma diferida, la latencia de llamadas lentas no bloquea el primer byte retornado.

    Respuesta: Son una abstracción RPC tipada que permite definir acciones en el servidor con validación y llamarlas desde formularios o cliente como si fueran funciones, reduciendo endpoints y errores de sincronía.

    Respuesta: CMS headless, Notion, bases SQL y APIs; la Content Layer las trata como colecciones locales durante el build con validación tipada y caching inteligente.

    Respuesta: No es ideal para aplicaciones con estado complejo e interactividad intensa en cliente (por ejemplo editores colaborativos o apps en tiempo real que dependen de una mentalidad SPA única).

    Respuesta: La nota de lanzamiento y el changelog están en astro.build/blog/astro-620/. La documentación de características específicas está en las guías: Server Islands, Actions y Content Collections en docs.astro.build.