HTML sobre WebSockets: SPAs en tiempo real con apenas JavaScript

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

Enviar HTML renderizado por el servidor a través de WebSockets como forma de construir aplicaciones de una sola página en tiempo real con JavaScript mínimo está generando debate entre los desarrolladores web. Sus defensores dicen que simplifica la gestión del estado, evita APIs de cliente complejas y puede superar a las SPAs tradicionales en muchas aplicaciones CRUD y herramientas internas, especialmente combinado con frameworks como LiveView, Hotwire, htmx o Datastar. Los críticos responden que HTTP/2+SSE suele lograr una latencia similar con menos riesgos operativos, que el estado de sesión mantenido en el servidor complica la escalabilidad y el caché, y que la industria se ha alejado repetidamente del renderizado acoplado en el servidor por buenas razones.

Reacción general a HTML sobre WebSockets

  • Muchos lo ven como “MPA con pasos extra” o como una reinvención de patrones antiguos (DHTML, WebForms, Meteor, ASP.NET Ajax, JSF Ajax).
  • Los defensores sostienen que ofrece “el 90% de los beneficios de una SPA con el 10% del código”: actualizaciones en tiempo real, sin una API JSON separada y con el servidor como única fuente de verdad.
  • Los críticos se preocupan por la redundancia frente a HTML renderizado en el servidor sin más, la infraestructura y los modos de fallo añadidos, y el hecho de que algunos cortafuegos corporativos bloquean WebSockets.

Comparaciones: WebSockets vs SSE vs HTTP

  • Varios argumentan que para la mayoría de las aplicaciones, SSE + fetch() es más simple, más fácil de operar y suficiente para actualizaciones en tiempo real de “solo envío”.
  • Otros responden que la latencia no es equivalente, especialmente en HTTP/1, y que WebSockets ofrecen mensajes garantizados en orden y protocolos bidireccionales útiles para chat, juegos y flujos de eventos complejos.
  • Se señalan limitaciones de SSE: solo texto, sin orden garantizado, y límites de conexiones por origen en HTTP/1.
  • La discusión toca HTTP/2/3, multiplexación y QUIC, y algunos mencionan WebTransport como una opción más reciente y de menor latencia.

Frameworks existentes y trabajos previos

  • Se citan múltiples frameworks que ya hacen “HTML sobre el cable”: Rails Turbo/Hotwire, Phoenix LiveView, Blazor Server, HTMX, Datastar, Laravel Livewire, Symfony Live Components, Inertia.js.
  • Una explicación detallada de Turbo frames/streams muestra cómo las actualizaciones parciales y las emisiones iniciadas por el servidor funcionan con muy poco JS.
  • Algunos argumentan que Datastar/HTMX con SSE + morphing del DOM ya ofrece beneficios similares sin WebSockets.

Arquitectura, estado y REST

  • Debate sobre si este enfoque es “RESTless”: el estado del servidor por conexión entra en conflicto con la naturaleza sin estado de REST, pero simplifica la programación para muchas herramientas internas.
  • A los defensores les gusta que todo el estado autorizado permanezca en el servidor, evitando desincronización entre cliente y servidor y reduciendo a la mitad el código frente a las SPAs.
  • Los escépticos destacan la escalabilidad, el balanceo de carga, el riesgo de DoS y la complejidad de monitorización para conexiones de larga duración.

Tradeoffs de experiencia de desarrollo y UX

  • Muchos agradecen evitar grandes bundles de JS y pipelines de compilación; otros prefieren modelos de SPA con datos como fuente de verdad (por ejemplo, Vue/React con esquemas tipados).
  • Quejas sobre efectos secundarios al reemplazar el DOM (pérdida de foco, saltos de desplazamiento); bibliotecas como idiomorph/Datastar intentan mitigarlo, pero añaden cableado.
  • La sensación general es que este modelo encaja mejor con paneles de administración, herramientas internas y aplicaciones moderadamente interactivas, y menos con UIs de consumo muy reactivas.

Meta: controversia sobre autoría con IA

  • Un artículo de seguimiento en la misma “saga” es acusado por varios comentaristas de haber sido generado por IA; el autor se defiende.
  • Esto desencadena una discusión lateral sobre normas de divulgación en torno a la IA generativa, la desconfianza de los lectores y el impacto en la autenticidad percibida de la escritura técnica.