Astro vs React: Cuándo el Framework es el Problema
React transformó la forma en que los desarrolladores construyen interfaces. Su modelo de componentes, su ecosistema de herramientas y su comunidad activa lo convirtieron en la opción predeterminada para casi cualquier proyecto web. Sin embargo, esa universalidad es precisamente su debilidad: cuando una herramienta se aplica sin discriminación, el contexto del problema desaparece.
Un portafolio profesional, un blog corporativo o una landing page de producto son fundamentalmente sitios de contenido. Su información cambia con poca frecuencia, su interactividad se limita a navegación y formularios, y su audiencia principal son motores de búsqueda y usuarios que necesitan respuestas rápidas. React, diseñado para aplicaciones interactivas con estados complejos, introduce una sobrecarga innecesaria en estos contextos.
El costo se manifiesta en tres dimensiones. Primera: el bundle de JavaScript. Una SPA de React típica envía entre 80KB y 200KB de JS al cliente solo para hidratar componentes que renderizan texto estático. Segunda: el SEO. Los motores de búsqueda pueden ejecutar JavaScript, pero priorizan el contenido que encuentran en el HTML inicial. Tercera: el Time to Interactive. El navegador debe descargar, parsear y ejecutar todo el JavaScript antes de que el usuario pueda interactuar con la página.
// Comparativa real: Portfolio SPA vs SSG
// React SPA:
// Bundle JS: ~150KB gzipped
// Time to Interactive: ~1.2s
// Lighthouse Performance: 72
// Astro SSG:
// Bundle JS: ~10KB gzipped (solo MatrixRain island)
// Time to Interactive: ~0.1s
// Lighthouse Performance: 98Astro resuelve esta tensión con un modelo mental diferente. En lugar de asumir que todo necesita JavaScript, parte de la premisa opuesta: el HTML estático es suficiente hasta que se demuestre lo contrario. Los componentes interactivos — un canvas animado, un formulario con validación, un filtro dinámico — se cargan como "islas" independientes, únicamente cuando el viewport los requiere.
Esta arquitectura no descarta React — lo contextualiza. En mi portafolio actual, el MatrixRain del hero es un componente React que se carga con client:visible. El resto de las 41 páginas son HTML puro generado en build time. El resultado es un sitio que se siente instantáneo, se indexa perfectamente y mantiene toda la interactividad donde realmente importa.
La lección es directa: el framework correcto es aquel que resuelve el problema con la menor complejidad posible. Si el problema es renderizar contenido estático con SEO óptimo, React es la respuesta equivocada. No porque sea mal framework, sino porque fue diseñado para otro tipo de desafío. // ARCHITECTURE_REVIEW: PASSED