No deberías empezar con una SPA

Artículo original ↗ Discusión en Hacker News ↗

Las aplicaciones de una sola página (SPA) están siendo reevaluadas como la opción predeterminada para nuevos proyectos web, y muchos ingenieros argumentan que los enfoques modernos renderizados en servidor (a menudo mejorados con herramientas como htmx, Hotwire o LiveView) ahora ofrecen una interactividad comparable con menos complejidad y sobrecarga operativa. Quienes defienden las SPA señalan ventajas para interfaces ricas y de larga duración, comportamiento offline o local-first, y APIs compartidas entre clientes web y móviles, mientras que los críticos destacan bundles de JavaScript más pesados, tooling frágil, rendimiento más lento en redes deficientes y un acoplamiento entre frontend y backend más estrecho de lo que se suele admitir. Un tema recurrente es que la arquitectura debe seguir las necesidades del producto y la estructura del equipo: las SPA pueden ser la opción adecuada para apps complejas y densas en datos con sesiones de usuario largas, pero se consideran excesivas para sitios más simples o equipos pequeños que se benefician de UIs integradas y dirigidas por el servidor.

Cuándo tiene sentido una SPA

  • Varios comentaristas sostienen que las SPA están justificadas para UIs complejas y muy interactivas (por ejemplo, paneles de administración ricos, apps con muchos datos, escenarios local-first/offline-first).
  • Otros sugieren que las SPA solo deberían elegirse cuando la profundidad de la sesión o el “holotype” de la app muestran que los usuarios se quedan e interactúan en profundidad, no para blogs sencillos o páginas de marketing.
  • Algunos creen que las SPA se volverán más simples gracias a herramientas más nuevas (Remix, Livewire, frameworks WASM como Blazor/Leptos).

Acoplamiento frente a desacoplamiento de frontend y backend

  • Un bando dice que el desacoplamiento الحقيقي es imposible: los frontends siempre dependen de las estructuras de datos del backend; los intentos de ocultar este límite son engañosos.
  • Otro bando informa de éxito con APIs públicas consumidas tanto por la UI como por usuarios avanzados, diseñadas desde el principio, con APIs simuladas que permiten trabajar en paralelo.
  • Hay un argumento recurrente de que el “backend for frontend” (endpoints por vista) reintroduce un acoplamiento estrecho incluso en sistemas nominalmente desacoplados.

Preocupaciones sobre tooling, JavaScript y escalado

  • Muchas quejas se centran en el tooling de las SPA: bundling, tiempos de compilación, invalidación de caché y bundles enormes que crecen con las funcionalidades y el tamaño del equipo.
  • Algunos argumentan que esto es inherente a las SPA; otros dicen que herramientas como esbuild, configuraciones más simples o no usar frameworks pesados mitigan el problema.
  • Debate sobre el propio JavaScript: algunos lo ven intrínsecamente desordenado; otros dicen que el “spaghetti” se debe más a las prácticas del equipo que a la elección del lenguaje.

UX, rendimiento y condiciones de red

  • Las voces a favor de las SPA citan navegaciones posteriores más rápidas, menos transferencia de datos mediante JSON, comportamiento adaptativo y mejores oportunidades para soporte offline y UI optimista.
  • Los críticos responden que los grandes bundles de JS perjudican la carga inicial, especialmente en redes lentas y dispositivos débiles, y que muchas SPA fallan de forma grave y opaca bajo problemas de red.
  • Hay desacuerdo sobre si las SPA realmente envían menos datos que HTML una vez que se consideran la compresión, el chrome de la interfaz y el sobrefetching.

Estructura organizativa, equipos y cultura

  • Algunos dicen que la arquitectura sigue naturalmente el organigrama (Ley de Conway); las divisiones SPA suelen reflejar equipos separados de frontend y backend.
  • Otros argumentan que elegir la arquitectura en función de la estructura organizativa es arriesgado; los flujos full-stack con UIs renderizadas en servidor y estrechamente acopladas pueden ser más productivos para equipos pequeños.
  • Críticas culturales: las SPA surgieron en parte porque los desarrolladores de frontend escapaban de frameworks centrados en backend, pero también por seguir modas y por adopción de “cargo cult”.

APIs, móvil y enfoques alternativos

  • Un lado sostiene que las apps móviles hacen que las APIs sean obligatorias de todos modos, por lo que la reutilización de SPA tiene sentido.
  • Otros responden que, en la práctica, móvil y web a menudo divergen lo suficiente como para que las APIs compartidas no aporten mucho.
  • Alternativas como htmx, Hotwire/Turbo, LiveView, Livewire y frameworks clásicos (Django/Rails/Laravel) se citan con frecuencia como opciones más simples y productivas que no son SPA.