Arquitectura Micro-frontend con Astro Islands: Mezclar React y Svelte
Por qué la Arquitectura de Islas de Astro convierte mezclar React y Svelte en un patrón de primera clase — y cómo decidir qué framework recibe qué componente según bundle size y necesidades de reactividad.
Publicar una página desde una SPA de React monolítica implica enviar todo el árbol de componentes al navegador — incluyendo las partes que nunca cambian. La Arquitectura de Islas de Astro invierte este comportamiento por defecto: todo es HTML estático a menos que explícitamente indiques que un componente debe hidratarse.
Esto cambia cómo piensas en la selección de frameworks.
Qué Son las Astro Islands
Una “isla” es un componente interactivo embebido en una página que de otro modo sería estática. El HTML circundante se envía sin JavaScript. La isla solo envía lo que necesita, hidratada de forma independiente.
---
import StaticCard from '@components/Astro/Card.astro';
import FilterComponent from '@components/Svelte/FilterComponent.svelte';
import SkillsDashboard from '@components/React/SkillsDashboard';
---
<!-- Sin JS — HTML puro -->
<StaticCard title="Portfolio" />
<!-- Svelte hidratado solo cuando entra al viewport -->
<FilterComponent client:visible />
<!-- React hidratado de inmediato — interactividad crítica -->
<SkillsDashboard client:load />La directiva client:* es el límite de hidratación. Sin ella, incluso los componentes de React y Svelte se renderizan como HTML estático.
La Decisión de Selección de Framework
Usar dos frameworks en un mismo proyecto no es un alarde. Es un tradeoff deliberado. Aquí el razonamiento real:
React para estado complejo e interconectado. El panel de administración y el dashboard de habilidades manejan múltiples fuentes de datos, estado derivado y actualizaciones optimistas. El ecosistema de React — useReducer, React Query, herramientas maduras — maneja esto mejor que el modelo más simple de Svelte a escala.
Svelte para reactividad local y ligera. La navegación, el componente de filtros y las interacciones de las tarjetas son autocontenidas. Svelte compila a JS puro sin runtime — el impacto en el bundle es mínimo. Un componente de filtros que reacciona a la entrada del usuario no necesita un DOM virtual.
La diferencia en bundle es medible:
| Componente | Framework | JS Gzipped |
|---|---|---|
| FilterComponent | Svelte | ~4 KB |
| Equivalente en React | React | ~42 KB + React runtime |
Para un componente que se carga en cada página, esa diferencia se acumula.
Estrategias de Hidratación
Astro expone cinco directivas de cliente, cada una con un perfil de rendimiento distinto:
client:load— hidratar de inmediato al cargar la página. Usar para componentes interactivos above-the-fold.client:idle— hidratar cuando el navegador está inactivo. Usar para widgets no críticos.client:visible— hidratar cuando el componente entra al viewport. Usar para contenido below-the-fold.client:media— hidratar solo cuando un media query de CSS coincide. Usar para interacciones exclusivas de responsive.client:only— omitir SSR completamente, renderizar solo en cliente. Usar cuando el componente requiere APIs del navegador no disponibles durante SSR.
La regla práctica: usar client:visible por defecto, promover a client:load solo cuando la primera interacción del usuario depende de ello.
Cómo Se Ve en Producción
El portafolio usa React para el panel de administración y la visualización de habilidades, Svelte para todos los componentes interactivos de cara al público (nav, filtros, tarjetas), y Astro para todo lo estructural. El resultado es una página que envía casi cero JavaScript a los visitantes que no interactúan con las islas interactivas.
El tradeoff no es “¿qué framework es mejor?”. Es “¿qué necesita este componente específico y cuál es el costo de enviarlo a cada usuario?”
