HTML over WebSockets 2026: SPAs en tiempo real con casi nada de JavaScript

HTML over WebSockets: SPAs en tiempo real con casi nada de JavaScript

Construir una aplicación de una sola página (SPA) tradicional implica un rompecabezas complejo: un framework JavaScript que dibuja la vista, una API que sirve JSON, y dos codebases independientes forzadas a entenderse mediante contratos. Es un escenario aceptado y profesionalizado, pero ser un estándar no lo convierte en la única forma. HTML over WebSockets representa un enfoque alternativo que ha ganado tracción en los últimos años, permitiendo construir SPAs en tiempo real con mínimo JavaScript y toda la lógica de renderizado en el backend.

Según el artículo original publicado el 12 de agosto de 2026, esta arquitectura mantiene el estado en el servidor, elimina la necesidad de construir una API separada, y ofrece comunicación bidireccional en tiempo real a través de WebSockets. La idea central es simple: en lugar de enviar JSON y ensamblar el HTML en el navegador, el servidor envía el HTML ya construido y el cliente solo lo coloca donde corresponde.

¿Cómo funciona realmente HTML over WebSockets?

En el sistema tradicional, el navegador hace una petición HTTP, recibe un JSON con datos crudos, y luego debe interpretarlos y construir el HTML correspondiente. Con HTML over WebSockets, esa misma petición viaja a través de un canal permanente y la respuesta es HTML ya ensamblado, sin JSON intermedio. Y como el canal nunca se cierra, el servidor puede incluso anticiparse y enviar cambios sin que el cliente lo solicite.

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

El flujo simplificado es:

El cliente abre una conexión WebSocket y se autentica (una sola vez)
El cliente envía un texto: «Quiero /article/2/»
El servidor consulta la base de datos
El servidor renderiza HTML con su motor de plantillas
El servidor devuelve el HTML/CSS/JS ensamblado
El cliente coloca el HTML donde corresponde

Chris McCord, creador de Phoenix (el framework más popular en el ecosistema Elixir), presentó esta tecnología llamada LiveView en ElixirConf 2019. En solo 15 minutos construyó un clon de Twitter que funcionaba en tiempo real sin agregar ningún JavaScript de renderizado ni un framework popular (React, Angular, Vue) para gestionar la vista.

Ventajas competitivas para startups tecnológicas

Reducción radical de complejidad: Solo hay un motor de renderizado, cortando drásticamente la complejidad del desarrollo. No necesitas construir una API: el servidor genera HTML y lo envía al cliente, sin intermediarios.

Estado en el servidor: No es request-response sin memoria: hay un proceso por cliente conectado que recuerda dónde está. Esto contrasta con htmx, que es deliberadamente stateless.

Conexión directa a la base de datos: Sin intermediarios JSON o GraphQL, lo que reduce latencia y simplifica el acceso a datos.

Tiempo real verdadero: Los clientes reciben cambios tan rápido como sea posible, sin necesidad de sondear al servidor.

Broadcast integrado: El servidor puede enviar cambios a todos los clientes conectados a la vez. Construir un chat, un dashboard o un juego multijugador viene incluido.

Menos tráfico y latencia: Una sola conexión persistente evita repetir el handshake TCP y los headers HTTP en cada interacción. No es que «el protocolo WebSocket sea mágicamente más rápido», sino que omites el viaje de ida y vuelta y envías HTML ensamblado.

SEO razonable: Como el HTML se renderiza en el servidor, la primera carga es indexable. Eso sí, un crawler no ve las actualizaciones que llegan después a través del WebSocket, por lo que el contenido importante debe estar en esa primera respuesta.

Desafíos y consideraciones prácticas

Más recursos en el servidor: El servidor mantiene un WebSocket abierto y, usualmente, el estado de cada cliente en memoria. Escalar horizontalmente obliga a compartir ese estado (en Django, con Channels + un servidor ASGI + Redis como capa de canal).

No funciona offline: Si la conexión cae, el sitio deja de funcionar. Hay que diseñar la experiencia de reconexión y tolerancia a fallos.

Curva de aprendizaje inicial más pronunciada: Ejecutar un servidor WebSocket no es trivial, y hay que aprender a manejar el patrón LiveView.

Latencia: Con mucha latencia física, la sensación de «instantaneidad» sufre.

El panorama actual: ¿qué frameworks existen?

El movimiento hypermedia ya tiene una implementación en casi todos los lenguajes principales. Según el artículo original, estos son algunos de los frameworks más relevantes:

Elixir: Phoenix LiveView (WebSocket) – Maduro (1.x, LiveView 1.0 en diciembre de 2024)
Ruby: Hotwire (Turbo + Stimulus) – HTTP + WebSocket/SSE (Streams)
Python/Django: Django LiveView (WebSocket) – Activo
Python/Django: Reactor (WebSocket) – Activo
C#/.NET: Blazor (Interactive Server) – WebSocket (SignalR) – .NET 9
PHP/Laravel: Livewire 3 + Reverb (WebSocket) – Reverb es el propio servidor WebSocket de Laravel (2024)
Agnóstico (JS): htmx – HTTP + extensiones WS/SSE
Agnóstico (JS): Datastar – SSE

Según CODERCOPS, Phoenix LiveView alcanzó la versión 1.0 en 2023, marcando un punto de estabilización donde equipos comenzaron a elegirlo no por ser algo nuevo, sino porque era la herramienta práctica para su caso de uso. Dos años después, LiveView no es exótico: es el framework web estándar de Elixir para aplicaciones interactivas.

¿Qué significa esto para tu startup en 2026?

Para founders tecnológicos que enfrentan decisiones de arquitectura, HTML over WebSockets representa una opción viable que puede reducir drásticamente los costos de desarrollo y acelerar el time-to-market para aplicaciones que requieren interactividad en tiempo real.

Acción 1: Evalúa si tu caso de uso se beneficia

Considera HTML over WebSockets si:

Necesitas funcionalidades colaborativas en tiempo real (chat, edición simultánea, dashboards)
Tu equipo tiene más experiencia en backend que en frontend moderno
Quieres mantener la lógica de negocio centralizada en el servidor
Tu aplicación no requiere funcionamiento offline

Evítalo si:

Tu interfaz requiere animaciones complejas o manipulación directa del DOM
Necesitas una aplicación que funcione completamente offline
Tu equipo ya domina React/Vue y tiene una arquitectura API bien establecida

Acción 2: Elige el framework según tu stack tecnológico

Si usas Python/Django, Django LiveView ofrece una integración nativa. Para Elixir, Phoenix LiveView es la opción madura y probada. Si estás en Laravel, Livewire 3 + Reverb proporciona una solución integrada. Y si prefieres algo agnóstico, htmx con extensiones WebSockets/SSE puede ser el punto de entrada más suave.

Acción 3: Comienza con un proyecto piloto

En lugar de reescribir toda tu aplicación, implementa una funcionalidad específica con HTML over WebSockets. Un dashboard en tiempo real, un sistema de notificaciones instantáneas, o un panel de administración colaborativo son excelentes candidatos para probar esta arquitectura sin comprometer todo tu sistema.

SSE: la opción económica cuando no necesitas bidireccionalidad

WebSockets es poderoso, pero mantener un canal bidireccional abierto por cliente tiene un costo. Y a menudo no lo necesitas: si el flujo es principalmente del servidor al cliente (notificaciones, un feed en vivo, un dashboard, los tokens de una respuesta de IA), Server-Sent Events (SSE) son suficientes.

Es la opción económica: la infraestructura más simple. Al no mantener un proceso con estado por cliente, es más fácil balancear carga y escalar. htmx tiene una implementación casi idéntica en espíritu con su extensión SSE.

La regla rápida: si necesitas comunicación bidireccional de baja latencia (chat, colaboración, juegos), WebSocket; si solo envías desde el servidor, SSE es más simple y económico de operar.

Conclusión: arquitectura sobre frameworks de moda

HTML over WebSockets no es la respuesta a todo, y ninguna de estas tecnologías lo es. El transporte está dictado por tu problema: si necesitas ida y vuelta en tiempo real (un chat, un panel en vivo, algo colaborativo), WebSockets; si solo envías desde el servidor, SSE; si request-and-response es suficiente, htmx sobre HTTP.

Cada proyecto es su propio mundo, con sus peculiaridades y límites. Si te llevas una cosa, que sea la idea subyacente: envía HTML en lugar de JSON, mantente en un solo lenguaje y tacha de tu lista la API, los contratos y la mitad del Front-End.

Confía en una buena arquitectura, no en frameworks o patrones de moda.