¿El fin de las Single Page Applications? El resurgimiento de las arquitecturas multi-página

Durante más de una década, las Single Page Applications (SPAs) han dominado el desarrollo web moderno. React, Vue y Angular se convirtieron en sinónimo de «aplicaciones web modernas». Sin embargo, en 2024-2025 estamos presenciando un cambio significativo: el retorno de las arquitecturas multi-página (MPAs) impulsadas por frameworks como Astro, junto con enfoques híbridos que desafían el paradigma establecido.

El reinado de las SPAs: ¿qué salió mal?

Las SPAs prometieron experiencias fluidas, similares a aplicaciones nativas, eliminando las recargas de página completa. Y en muchos casos, cumplieron esa promesa. Pero también trajeron desafíos inesperados:

Problemas de rendimiento

El JavaScript se convirtió en el cuello de botella. Enviar megabytes de código JS al navegador significa tiempos de carga iniciales lentos, especialmente en dispositivos móviles o conexiones lentas. El Time to Interactive (TTI) sufre cuando el navegador debe descargar, parsear y ejecutar todo ese código antes de que la página sea utilizable.

Complejidad innecesaria

No todas las aplicaciones web necesitan la interactividad de Gmail o Figma. Un blog, un sitio corporativo o incluso muchos e-commerce terminaron con stacks tecnológicos complejos para resolver problemas que no tenían. La hydration (rehidratación del HTML estático con JavaScript) añadió capas de complejidad y oportunidades para bugs.

SEO y accesibilidad

Aunque el SEO para SPAs mejoró con el tiempo, siempre ha sido más complejo. El contenido renderizado en el cliente requiere soluciones como SSR (Server-Side Rendering), lo que ironicamente significa ejecutar JavaScript en el servidor para generar HTML… que luego se vuelve a hidratar en el cliente.

El resurgimiento de las MPAs: volver a los fundamentos

Las arquitecturas multi-página no son nuevas, son la forma original de construir para la web. Pero los nuevos frameworks las están reinventando con herramientas modernas.

Astro: el líder del renacimiento

Astro popularizó el concepto de «arquitectura de islas» (Islands Architecture). La filosofía es radical pero simple: envía cero JavaScript por defecto. Solo agregas interactividad donde realmente la necesitas.

---
// Componente Astro - se renderiza a HTML puro
const posts = await fetch('/api/posts').then(r => r.json());
---

<div class="blog-grid">
  {posts.map(post => (
    <article>
      <h2>{post.title}</h2>
      <p>{post.excerpt}</p>
    </article>
  ))}
</div>

<!-- Solo este botón interactivo carga JavaScript -->
<ShareButton client:load />

Los componentes se renderizan a HTML estático en build time o en el servidor. Solo las «islas» de interactividad (un carrito de compras, un formulario con validación en tiempo real) cargan JavaScript.

Otros actores en el escenario

Eleventy (11ty): Un generador de sitios estáticos minimalista que permite usar múltiples lenguajes de plantillas. Perfecto para sitios de contenido sin JavaScript innecesario.

SvelteKit y Solid Start: Aunque soportan SPAs, priorizan el Server-Side Rendering y permiten progressive enhancement, enviando solo el JS necesario.

Qwik: Lleva el concepto más lejos con «resumability», donde el framework serializa el estado de la aplicación y lo «reanuda» en el cliente sin re-ejecutar código.

Arquitecturas híbridas: lo mejor de dos mundos

La conversación real no es SPA vs MPA, sino cuándo usar cada patrón. Los frameworks modernos permiten mezclarlo:

Next.js y el App Router

Next.js evolucionó de ser un framework React con SSR a soportar React Server Components. Ahora puedes tener:

• Páginas completamente estáticas (MPA)
• Server Components que nunca envían JS al cliente
• Client Components para interactividad específica
• Streaming para cargar contenido progresivamente

El patrón PRPL de Chrome

Progressive, Render, Pre-cache, Lazy-load. Las Service Workers permiten que las MPAs se comporten como SPAs para navegaciones subsecuentes, manteniendo beneficios de rendimiento inicial.

¿Cuándo usar cada enfoque?

Elige SPAs cuando necesites:

• Interactividad constante: Editores en tiempo real (Figma, Google Docs, Notion)
• Estado complejo compartido: Dashboards con múltiples vistas interdependientes
• Experiencias offline-first: PWAs que funcionan sin conexión
• Transiciones complejas: Aplicaciones donde la UX fluida es crítica para la experiencia

Ejemplos: herramientas de productividad, aplicaciones de mensajería, plataformas de trading, juegos web.

Elige MPAs cuando tengas:

• Contenido estático o semi-estático: Blogs, documentación, sitios corporativos
• SEO crítico: E-commerce, sitios de noticias, portales de contenido
• Audiencia en dispositivos limitados: Mercados con conexiones lentas o hardware modesto
• Simplicidad prioritaria: Equipos pequeños, proyectos con mantenimiento limitado

Ejemplos: marketing sites, blogs, portfolios, sitios de noticias, documentación técnica.

Considera híbridos cuando:

• Tienes mayormente contenido estático con zonas interactivas (e-commerce con carrito dinámico)
• Necesitas buen rendimiento inicial Y experiencia fluida subsecuente
• Diferentes secciones tienen necesidades diferentes de interactividad
• Quieres optimizar Core Web Vitals sin sacrificar UX

Métricas que importan

Los Core Web Vitals de Google favorecen las MPAs modernas:

Largest Contentful Paint (LCP): Las MPAs ganan al enviar HTML renderizado inmediatamente, sin esperar JavaScript.

Interaction to Next Paint (INP): Menos JavaScript significa menos trabajo en el main thread, respuestas más rápidas.

Cumulative Layout Shift (CLS): El HTML estático es inherentemente más estable que contenido renderizado dinámicamente.

El futuro es contextual

El «fin de las SPAs» es un titular provocador, pero impreciso. Lo que realmente está ocurriendo es una maduración del ecosistema. La comunidad está aprendiendo que:

1. El JavaScript tiene un costo que debe justificarse con valor real para el usuario
2. La arquitectura debe seguir a los requisitos, no a las modas
3. Los web standards evolucionaron y ahora ofrecen capacidades que antes requerían JS pesado
4. El rendimiento es una característica que impacta directamente conversiones y accesibilidad

Las SPAs no van a desaparecer. Gmail, Figma, VSCode Web y miles de aplicaciones complejas seguirán siendo SPAs porque es la arquitectura correcta para ellas. Pero para la mayoría de sitios web, especialmente aquellos centrados en contenido, las arquitecturas MPA modernas o híbridas ofrecen mejor rendimiento, simplicidad y experiencia de usuario.

Conclusión

Estamos entrando en una era más pragmática del desarrollo web. Los nuevos frameworks nos dan herramientas para enviar menos JavaScript, renderizar en el servidor cuando tiene sentido, y agregar interactividad solo donde aporta valor.

La pregunta ya no es «¿SPA o MPA?», sino «¿cuánto JavaScript realmente necesita esta experiencia?». Y cada vez más, la respuesta es: menos del que pensábamos.

---

Recursos para profundizar:

• Documentación de Astro sobre Islands Architecture
• «Islands Architecture» por Jason Miller (creador de Preact)
• Performance insights de los equipos de Chrome y Lighthouse
• Comparativas de benchmarks en WebPageTest entre diferentes arquitecturas