Astro y Svelte: Por Qué Creo Que Son el Futuro del Desarrollo Web

Recuerdo cuando construir un sitio web era algo simple. Abrías un editor de texto, escribías HTML, vinculabas una hoja de estilos CSS, y si necesitabas algo interactivo, ponías un script tag. Funcionaba. Sin bundlers, sin transpilers, sin un ritual de configuración antes de poder renderizar “Hello World.”

Entonces decidimos que eso no era suficiente.

---

El Problema de la Sobre-Ingeniería

En algún punto del camino, construir para la web se volvió innecesariamente complejo. Empezamos a necesitar build pipelines para publicar una landing page. React popularizó la arquitectura basada en componentes, pero con ella llegaron hooks, efectos, dependency arrays, reconciliación de virtual DOM. Y otros frameworks siguieron el mismo camino.

He trabajado principalmente con Vue a lo largo de mi carrera. Lo elegí por su promesa de simplicidad — Evan You lo creó después de trabajar con Angular en Google, buscando algo más accesible. Y por un tiempo, lo logró. La Options API de Vue 2 era genuinamente intuitiva: data(), computed, methods, watch. Limpio, organizado, fácil de entender. Construí proyectos con él. Lo defendí.

Pero entonces llegó Vue 3 con la Composition API, y empecé a ver el mismo patrón. El framework que había elegido porque era más simple que React se estaba volviendo gradualmente igual de complejo:

<script setup>
import { ref, computed, watchEffect } from 'vue';

const count = ref(0);
const title = computed(() => `Count: ${count.value}`);

watchEffect(() => {
  document.title = title.value;
});
</script>

<template>
  <div>
    <p>Count: {{ count }}</p>
    <button @click="count++">
      Increment
    </button>
  </div>
</template>

No es terrible. Pero fíjate en lo que ocurrió: ref(), .value por todas partes, computed(), watchEffect(), defineProps, defineEmits… Vue empezó como el “React más simple” y gradualmente absorbió la misma complejidad que estaba diseñado para evitar. La Composition API es poderosa, pero añadió una curva de aprendizaje que la Options API nunca tuvo.

Elegí Vue sobre React por su simplicidad, y ahora Vue recorría el mismo camino. Los frameworks que empiezan simples inevitablemente se vuelven complejos al intentar cubrir todos los casos de uso. React lo hizo primero. Vue lo siguió. Angular nació complejo.

Eso fue lo que me llevó a Astro y Svelte.

La mayoría de los sitios web son fundamentalmente sitios de contenido — blogs, portfolios, documentación, páginas de marketing. Mayormente estáticos. Una pared de texto con algunas imágenes, quizás un formulario de contacto o una barra de búsqueda. Y sin embargo enviamos cientos de kilobytes de código de framework para mostrar contenido que no ha cambiado desde el último build.

---

Astro: De Vuelta a los Orígenes

Astro cambió cómo pienso sobre todo esto. Cuando lo probé por primera vez, mi reacción fue inmediata: ah. Así es como debería funcionar.

Un componente de Astro:

---
const title = "Hello World";
const posts = await fetch('/api/posts').then(r => r.json());
---

<section>
  <h1>{title}</h1>
  <ul>
    {posts.map(post => (
      <li><a href={post.url}>{post.title}</a></li>
    ))}
  </ul>
</section>

<style>
  section { max-width: 800px; margin: 0 auto; }
</style>

El frontmatter (entre los separadores ---) se ejecuta en build time — obtiene datos, importa componentes, procesa lo que necesites. El template de abajo es HTML con expresiones. Los estilos tienen scope. Sin virtual DOM. Sin runtime. Sin useEffect. Sin dependency arrays. Sin hydration del lado del cliente por defecto.

¿El resultado? HTML estático puro. Cero JavaScript enviado al navegador a menos que lo pidas explícitamente.

Astro recupera la simplicidad de escribir HTML con un script tag, pero con una experiencia de desarrollo moderna — TypeScript, arquitectura de componentes, data fetching en build time, output optimizado. Sin ref(), sin .value, sin useState. Solo HTML.

La idea central es esta: tu sitio web probablemente no necesita JavaScript. No en todas partes. La mayoría de las páginas son contenido. El contenido no necesita un runtime. Necesita HTML.

Cuando sí necesitas interactividad — una barra de búsqueda, un menú de navegación, un toggle de tema — Astro usa la Islands Architecture. En lugar de hidratar la página entera, hidratas componentes individuales:

---
import Header from '@/components/layout/Header.svelte';
import BlogSearch from '@/components/blog/StaticBlogSearch.svelte';
---

<!-- Hydrate immediately — navigation needs to work right away -->
<Header client:load lang="en" />

<!-- Hydrate when visible — search isn't needed until scrolled to -->
<BlogSearch client:visible posts={posts} />

<!-- Everything else? Zero JavaScript. Pure HTML. -->
<article>
  <h1>{post.title}</h1>
  <p>{post.content}</p>
</article>

Controlas exactamente cuándo y cómo carga cada pieza interactiva:

• client:load — Hidrata inmediatamente (UI crítica)
• client:visible — Hidrata cuando aparece en pantalla
• client:idle — Hidrata cuando el navegador está inactivo

¿Una página con 95% de contenido estático y un componente de búsqueda? Solo el componente de búsqueda envía JavaScript. Todo lo demás es HTML de costo cero. En una app de Vue o React, incluso una página mayormente estática envía el runtime completo del framework — decenas de kilobytes antes de haber escrito una sola línea de código propio.

---

Svelte: El Compañero Perfecto

Si Astro es la base, Svelte es su pareja ideal. He trabajado principalmente con Vue a lo largo de mi carrera, y me encanta. Pero Svelte es diferente. Se siente como lo que Vue siempre quiso ser pero no pudo lograr del todo por su arquitectura basada en runtime.

El mismo contador en Svelte:

<script>
  let count = $state(0);
  let title = $derived(`Count: ${count}`);
</script>

<svelte:head>
  <title>{title}</title>
</svelte:head>

<p>Count: {count}</p>
<button onclick={() => count++}>
  Increment
</button>

Compara esto con la versión de Vue. Sin ref(). Sin .value. Sin computed(). Sin imports del framework. Declaras el estado con $state(), los valores derivados con $derived(), y el compilador resuelve el resto. Genera el código mínimo de actualización del DOM en build time — sin diffing de virtual DOM en runtime.

El código se lee casi como HTML vanilla con reactive sprinkles. Los cambios de estado actualizan el markup. Sin capas de abstracción. Es lo que la Options API de Vue se sentía — pero sin las limitaciones que llevaron a Vue a la Composition API.

Svelte 5 Runes

Svelte 5 introdujo los Runes — un sistema de reactividad basado en signals. La API es pequeña:

• $state() — Estado reactivo
• $derived() — Valores calculados
• $effect() — Side effects
• $props() — Props del componente

Un ejemplo real — un componente de búsqueda. Primero, Vue 3:

<script setup>
import { ref, computed } from 'vue';

const props = defineProps(['posts', 'lang']);
const query = ref('');
const currentPage = ref(1);

const filtered = computed(() =>
  query.value.length > 2
    ? props.posts.filter(p => p.title.toLowerCase().includes(query.value.toLowerCase()))
    : props.posts
);

const paginated = computed(() =>
  filtered.value.slice((currentPage.value - 1) * 12, currentPage.value * 12)
);

const totalPages = computed(() => Math.ceil(filtered.value.length / 12));
</script>

<template>
  <input v-model="query" placeholder="Search posts..." />
  <article v-for="post in paginated" :key="post.id">
    <h3>{{ post.title }}</h3>
    <p>{{ post.description }}</p>
  </article>
  <span>Page {{ currentPage }} of {{ totalPages }}</span>
</template>

Ahora en Svelte:

<script>
  let { posts, lang } = $props();
  let query = $state('');
  let currentPage = $state(1);

  let filtered = $derived(
    query.length > 2
      ? posts.filter(p => p.title.toLowerCase().includes(query.toLowerCase()))
      : posts
  );

  let paginated = $derived(
    filtered.slice((currentPage - 1) * 12, currentPage * 12)
  );

  let totalPages = $derived(Math.ceil(filtered.length / 12));
</script>

<input bind:value={query} placeholder="Search posts..." />

{#each paginated as post}
  <article>
    <h3>{post.title}</h3>
    <p>{post.description}</p>
  </article>
{/each}

<span>Page {currentPage} of {totalPages}</span>

La diferencia es evidente. Vue necesita ref() para cada estado, .value para accederlo, computed() para valores derivados, defineProps para props. Funciona — he escrito este mismo componente en Vue decenas de veces — pero hay fricción en todas partes. El unwrapping de .value solo ya es una fuente constante de bugs.

En Svelte, el estado es $state(). Los valores derivados son $derived(). Los props se desestructuran de $props(). Sin .value. Sin imports del framework. El compilador rastrea dependencias y genera el código mínimo de actualización. Menos ceremonia, mismo resultado.

Compilado, No en Runtime

La innovación central de Svelte es que es un compilador, no una librería. Mientras Vue envía un runtime (~30KB min+gzip) que maneja el diffing de virtual DOM y los proxies de reactividad en el navegador, Svelte hace todo ese trabajo en build time. El output es JavaScript vanilla que hace actualizaciones quirúrgicas del DOM.

Para un sitio Astro que ya envía cero JavaScript por defecto, esto importa. Cuando sí necesitas un interactive island, Svelte lo mantiene pequeño. Los componentes compilan a 30-40% menos JavaScript que los equivalentes en Vue o React.

Por Qué Funcionan Juntos

Astro genera HTML estático en build time. Svelte compila a JavaScript mínimo en build time. Juntos, las partes estáticas no cuestan nada y las partes interactivas envían lo mínimo absoluto. Sin impuesto de hydration para contenido que nunca cambia.

La sintaxis también se siente natural. Astro usa un patrón frontmatter + template. Svelte usa un patrón script + template. Moverse entre ellos es fluido.

Un ejemplo de mi sitio — la búsqueda del blog es un componente Svelte dentro de una página Astro:

---
// Astro: runs at build time
import StaticBlogSearch from '@/components/blog/StaticBlogSearch.svelte';
import { getBlogPosts } from '@/lib/blog';

const posts = await getBlogPosts('en');
---

<!-- Svelte component hydrated only when visible -->
<StaticBlogSearch client:visible posts={posts} lang="en" />

Data fetching en build time en Astro. Búsqueda interactiva en runtime en Svelte. Cada framework hace lo que mejor sabe hacer.

---

Lo Que Dicen las Encuestas

¿Soy simplemente un fanático, o la comunidad realmente se está moviendo en esta dirección? Miré los números.

La encuesta State of JS 2025 cuenta una historia clara: Astro es #1 en satisfacción con una ventaja de 39 puntos sobre Next.js. Svelte mantiene una retention rate del 88%. La encuesta llamó a Astro un “competidor peligroso” para Next.js — y eso fue antes de la adquisición de Cloudflare.

La edición 2024 fue similar: Astro clasificó #1 en interés, retención y positividad entre los meta-frameworks. Dos años consecutivos en lo más alto. Eso no es casualidad.

GitHub Rising Stars 2025 registró +7.200 estrellas para Astro, +4.600 para Svelte. Stack Overflow 2025 mostró a Svelte con un 53.7% de admiración. Los números apuntan todos en la misma dirección: quienes prueban estas herramientas siguen usándolas.

No voy a fingir que las encuestas lo son todo — miden sentimiento, no destino. Pero cuando satisfacción, retención y crecimiento suben durante dos años seguidos, algo real está pasando.

---

Rendimiento

Filosofía y encuestas aparte — ¿funciona en la práctica?

Astro envía 90% menos JavaScript que Next.js para contenido estático equivalente. En una comparación del mundo real, un sitio en Next.js empaquetó 180 KB de JavaScript para el mismo contenido que Astro entregó con 18 KB. Eso no es optimización — es una arquitectura fundamentalmente diferente.

Los sitios en Astro alcanzan consistentemente puntajes de Lighthouse Performance de 98-100 por defecto. Migraciones del mundo real: WordPress a Astro ve los puntajes saltar de los 70s a 96+. Mejoras de LCP de 3.2s a 1.6s. 60% de los sitios en Astro logran Core Web Vitals “Good”, comparado con 38% para WordPress y Gatsby.

En mi propio sitio, xergioalex.com, los resultados son un poco absurdos. No es un landing page simple — tiene un blog en crecimiento en dos idiomas, búsqueda del lado del cliente, timelines interactivos, lightboxes de imágenes, dark mode, routing bilingüe, y decenas de componentes Svelte. Y aun así logra un 100 perfecto en las cuatro categorías de PageSpeed — Performance, Accessibility, Best Practices y SEO — tanto en mobile como en desktop:

Desktop — 100/100/100/100:

Mobile — 100/100/100/100:

Desktop: 0.3s FCP, 0.3s LCP, 0ms TBT, 0 CLS. Mobile: 0.9s FCP, 1.5s LCP, 0ms TBT. Lograr un cuádruple 100 en desktop ya es bueno, pero en mobile — donde el throttling de Google es agresivo — es donde se complica de verdad. Con Astro + Svelte, la arquitectura trabaja contigo. Los defaults ya son rápidos; solo evitas frenarlo activamente.

Si quieres la historia completa — el Typewriter CSS-only, la auditoría WCAG AA, la optimización de directivas de hydration — escribí un deep dive: El Camino al 100: Cómo Logré Puntajes Perfectos de Lighthouse en Cada Categoría.

Estas bases de rendimiento también habilitaron algo que no había planeado inicialmente: optimizar el sitio para que los agentes de IA lo encuentren y lo citen. En mi serie AEO: De Invisible a Citado, documento cómo pasé de ser completamente invisible para los motores de IA a ser citado por ChatGPT, Perplexity y otros — y la arquitectura static-first de Astro fue un habilitador clave. Tiempos de carga rápidos, HTML semántico limpio y datos estructurados son exactamente lo que los crawlers de IA necesitan, y Astro entrega todo eso por defecto. Además, el soporte nativo de Markdown y MDX de Astro resultó ser una ventaja enorme — estamos en la era del Markdown for Agents, donde los modelos de IA consumen contenido en Markdown mucho mejor que HTML crudo, y Astro ya trabaja en ese formato de forma natural.

El rendimiento importa porque impacta todo lo que se construye encima — experiencia de usuario, SEO, accesibilidad en conexiones lentas, costos de hosting, y ahora también, que los agentes de IA encuentren tu contenido. Cuando un stack te da todo eso por defecto, no es un extra. Es una ventaja compuesta.

---

La Adquisición de Cloudflare

En enero de 2026, Cloudflare adquirió The Astro Technology Company. Una empresa con una capitalización de mercado que supera los $40 mil millones decidió que Astro era suficientemente importante como para adquirirlo.

Lo que importa: Astro sigue siendo MIT-licensed, open-source y agnóstico de plataforma. Puedes seguir deployando en cualquier lugar. El equipo puede enfocarse en el framework en lugar de construir un negocio alrededor de él. Y ahora hay dinero institucional respaldando el ecosistema — Webflow ($150K), Cloudflare ($150K), Mux, Netlify, Wix y Sentry contribuyendo al Astro Ecosystem Fund.

Esto ya no es un experimento de startup. Empresas como Microsoft (Fluent 2 Design System), Google, Firebase (que migró su blog de Blogger a Astro), Trivago, Visa, NBC News y Unilever usan Astro en producción. 87% de los usuarios de Astro planean seguir usándolo — la intención de retención más alta entre todos los SSGs encuestados.

Este mismo sitio corre sobre Cloudflare Pages. Migré desde GitHub Pages y la diferencia fue inmediata — CDN global, preview deployments por branch, y cero configuración para Astro. Si te interesa el proceso, escribí sobre eso: La Mejor Forma de Desplegar tu Sitio Astro Gratis.

---

Mi Experiencia: Este Sitio Es la Prueba

No solo leí sobre Astro y Svelte — construí toda mi plataforma personal con ellos. XergioAleX.com tiene:

• Un blog en crecimiento en dos idiomas (inglés y español)
• Arquitectura bilingüe completa — cada página, cada string de UI, cada post en ambos idiomas
• Búsqueda del lado del cliente impulsada por un índice JSON estático, lazy-loaded con requestIdleCallback
• Decenas de componentes Svelte interactivos — navegación, búsqueda, lightbox, timelines
• Dark mode con detección del sistema y persistencia en localStorage
• RSS feeds, sitemap, optimización SEO — todo integrado con Astro

Escribí sobre el proceso completo en Construyendo XergioAleX.com. La versión corta: construir con Astro + Svelte se siente como la web temprana con superpoderes modernos. Componentes que parecen HTML. Seguridad de TypeScript. Builds rápidos. Y el output más liviano que he lanzado.

Para los curiosos, el stack:

Capa	Tecnología	Rol
Framework	Astro 5.x	Generación de sitio estático, routing, Content Collections
UI Interactiva	Svelte 5.x	Búsqueda, navegación, lightbox, timelines
Estilos	Tailwind CSS 4.x	CSS utility-first con dark mode
Contenido	Markdown/MDX	Posts del blog con validación de frontmatter
Tipado	TypeScript 5.x	Desarrollo type-safe
Linting	Biome	Linter y formatter rápido
Deploy	Cloudflare Pages	CDN global, edge caching
Búsqueda	Fuse.js	Búsqueda fuzzy del lado del cliente, lazy-loaded

Cada elección refuerza la misma idea: la herramienta más simple que hace bien el trabajo. Biome en lugar de ESLint + Prettier. Tailwind en lugar de CSS-in-JS. Cloudflare Pages en lugar de un servidor.

---

Cuándo Elegir Otra Cosa

Hay que ser honesto: Astro no es la herramienta correcta para todo proyecto.

Sobresale en sitios de contenido, sitios mayormente estáticos, sitios críticos en rendimiento y sitios con mucho SEO. No es la opción natural para SPAs completamente interactivas — apps como Figma o Google Docs donde el 100% de la página es un canvas interactivo en vivo.

Para dashboards en tiempo real, diría que Astro aún funciona — la barra lateral, la navegación y la estructura de la página son contenido estático, y los gráficos en vivo son islands de Svelte con conexiones WebSocket. Para estado complejo, los runes de Svelte 5 más nanostores manejan más de lo que uno esperaría.

Pero para apps donde la interactividad domina en cada pantalla — un SaaS completo con docenas de vistas complejas — Vue con Nuxt, React con Next.js, o SvelteKit son opciones más naturales. Esos frameworks se ganaron su lugar.

La mayoría de los sitios web no son Figma, sin embargo. La mayoría son una mezcla de contenido e interactividad. Para esos — que representan la gran mayoría de lo que se construye — Astro y Svelte no son solo competitivos. Son mejores.

---

Pruébalo Tú Mismo

Si algo de esto resonó, construye algo pequeño. Un blog. Un portfolio. Un sitio de documentación. Vas a sentir la diferencia.

• Documentación de Astro — Empieza aquí
• Documentación de Svelte — El tutorial interactivo es muy bueno
• State of JS 2025 — Los datos completos de la encuesta
• Astro Year in Review 2025 — La historia de crecimiento
• Cloudflare Adquiere Astro — La adquisición

Estás mirando un sitio Astro + Svelte real ahora mismo. Revisa Construyendo XergioAleX.com para la historia completa.

A seguir construyendo — pero más simple.