Guías

«SPA vs PWA» es una de las confusiones más habituales en el desarrollo front-end, y la razón es sencilla: los dos términos no son opuestos en absoluto. Una single-page application (SPA) describe cómo se construye una aplicación y cómo navega, mientras que una progressive web app (PWA) describe qué puede hacer una aplicación por el usuario. Enfrentarlas es un poco como preguntar «coche manual o eléctrico»: estás comparando dos ejes distintos, y una aplicación puede ser perfectamente ambas, una sola, o ninguna.

Qué es una SPA

Una single-page application carga un único documento HTML y luego reescribe la página en el navegador según navegas, en lugar de pedir una página nueva al servidor en cada clic. Tras la primera carga, el JavaScript sustituye las partes relevantes de la interfaz y solo trae los datos que necesita, normalmente como JSON desde una API. El resultado se siente más cercano a una aplicación de escritorio o móvil, con transiciones instantáneas y sin recargas completas de página. React, Vue, Svelte y Angular existen en gran medida para hacer práctico este modelo.

Qué es una PWA

Una progressive web app es una idea completamente distinta: es un sitio web que usa los estándares web modernos para comportarse más como una aplicación instalada. Los tres pilares son un manifest de aplicación web (para poder añadirla a la pantalla de inicio con un icono y un nombre), un service worker (un script capaz de cachear recursos y servirlos sin conexión) y HTTPS (necesario para esas capacidades). Una PWA puede enviar notificaciones push, funcionar sin conexión y abrirse en su propia ventana, todo desde una URL normal, sin tienda de aplicaciones.

• SPA = arquitectura (navegación en el cliente, sin recargas)
• PWA = capacidades (instalable, sin conexión, push)
• Una PWA suele ser una SPA, pero ninguna exige a la otra
• El SSR es un eje aparte (renderizado, no tipo de aplicación)
• Elige según lo que necesita el producto y luego suma funciones

Por qué no son opuestos

Este es el meollo de la confusión que conviene aclarar: las dos no son mutuamente excluyentes. Una PWA se construye muy a menudo como una SPA, pero no tiene por qué serlo: puedes añadir un manifest y un service worker a un sitio multipágina tradicional y convertirlo en una PWA. Del mismo modo, muchas SPA no son PWA en absoluto, porque nunca añaden soporte sin conexión ni instalabilidad. La SPA trata sobre la arquitectura de navegación; la PWA trata sobre la entrega y las capacidades que se añaden por encima.

Las concesiones de una SPA

Visto por sí solo, el modelo SPA te da interactividad fluida a cambio de un coste. Una vez cargado el bundle, las interacciones son rápidas porque la aplicación pide datos en lugar de documentos enteros. Pero la primera carga es más pesada —el navegador debe descargar y ejecutar JavaScript antes de mostrar contenido útil— y los motores de búsqueda pueden ver una cáscara vacía a menos que renderices en el servidor. Las SPA destacan en paneles, editores y productos de tipo aplicación, y menos en sitios de contenido sencillo.

Las concesiones de una PWA

Las capacidades de una PWA resuelven un problema distinto: la reconexión y la resiliencia. El soporte sin conexión significa que la aplicación sigue funcionando con una conexión de tren inestable; la instalabilidad coloca un icono en la pantalla de inicio y elimina el marco del navegador; las notificaciones push traen de vuelta a los usuarios. Las contrapartidas también son reales: los service workers añaden una complejidad de caché que puede servir contenido obsoleto si se gestiona con descuido, y el soporte de Apple en iOS, aunque ha mejorado mucho, todavía va por detrás de Android en algunos aspectos.

Dónde encaja el SSR

Un tercer término suele irrumpir en esta comparación: el SSR, o renderizado en el servidor. Merece la pena separarlo porque es otro eje más: una estrategia de renderizado, no un tipo de aplicación. Los meta-frameworks como Nuxt y Next.js renderizan la primera página en el servidor para que usuarios y motores de búsqueda obtengan contenido real de inmediato, y luego la hidratan en una SPA en el navegador. Puedes combinar SSR con una SPA, y una PWA también puede usar SSR; ninguna de estas etiquetas descarta a las demás.

Cómo elegir

Entonces, ¿cómo elegir en la práctica? Parte de lo que necesita el producto, no del acrónimo. Si es muy interactivo y se comporta como software, la arquitectura SPA encaja. Si a los usuarios les vendría bien el acceso sin conexión, la instalabilidad o las notificaciones push, añade las capacidades PWA por encima: es incremental por diseño, que es justo lo que significa «progressive». Si el sitio es sobre todo contenido y el SEO es lo más importante, apóyate en el renderizado en el servidor o incluso en un enfoque multipágina tradicional, y añade funciones PWA solo donde realmente compensen.

En resumen

La conclusión honesta es que «SPA vs PWA» es el planteamiento equivocado. Son capas complementarias: una decide cómo navega tu aplicación, la otra decide qué puede hacer una vez que está ahí. Las aplicaciones web modernas más sólidas a menudo combinan las tres ideas —una SPA para la interactividad, el renderizado en el servidor para un primer pintado rápido y el SEO, y las funciones PWA para el modo sin conexión y la instalabilidad—, elegidas de forma deliberada en lugar de tratarse como bandos rivales.