Radar Tech: O HTML voltou ao servidor — o caso arquitetural do HTML over WebSockets (e quando a SPA ainda vence)

No radar das últimas 24 horas, um ensaio técnico dominou a discussão no Hacker News: "HTML over WebSockets: real-time SPAs with barely any JavaScript", de Andros Fenollosa (Top 7 do HN). Em poucas horas, o texto reabriu um debate que toda equipe de arquitetura enfrenta: onde o render e o estado de uma aplicação web devem viver — no servidor ou no browser?

O que é o padrão

A ideia não é nova, mas vem ganhando tração desde o LiveView do Phoenix (apresentado por Chris McCord na ElixirConf 2019). Em vez de o browser baixar um framework JS, chamar uma API REST e montar o HTML no client, o servidor envia o HTML já pronto e o client apenas o coloca no DOM. Toda a lógica de render fica no backend, em uma única linguagem, sem contratos de API.

O que muda conforme o transporte do HTML:

• HTML over HTTP — requisição por requisição, deliberadamente stateless (htmx, Turbo/Hotwire).
• HTML over SSE — canal contínuo em uma via, servidor → client (Datastar).
• HTML over WebSockets — canal persistente e bidirecional (Phoenix LiveView, Django LiveView, Laravel Reverb, Blazor Server).

No caso do WebSocket, há um processo por cliente conectado no servidor que guarda o estado daquela sessão, e o servidor pode empurrar mudanças (broadcast) para todos os clientes de uma vez — chat, dashboards ao vivo e colaboração "de graça", sem polling.

Por que é uma decisão de arquitetura — não de framework

O ganho não é "WebSocket é mais rápido". O próprio artigo ressalta que HTTP/2 e HTTP/3 fecharam boa parte do gap em request-response. O valor está em pular o round-trip, mandar HTML pronto e manter o estado no servidor. São três consequências arquiteturais profundas:

• Estado: no live view o estado vive no servidor (memória por conexão); na SPA ele vive (e dessincroniza) no client. Cada abordagem tem custos opostos.
• Escala: estado server-side e conexões persistentes implicam sticky sessions, memória por conexão e, para broadcast multi-nó, uma camada de pub/sub / mensageria (a parte event-driven). É um custo de infra real.
• SEO e público: render server-side é indexável; mas para leitura massiva e cache/CDN a SPA stateless ainda domina.

Quando a SPA ainda vence

Não é uma troca direta. A SPA continua certa quando há muitos estados complexos de UI (editores, canvas, mapas densos), quando a leitura massiva precisa de cache/CDN, quando o time front já é maduro e autônomo, ou quando a infra bloqueia WebSockets (e o fallback via SSE é o plano B). O caso típico mais atraente é o híbrido: páginas públicas via HTTP over the wire (crawlable e cacheável) + painel autenticado real-time via WebSocket com broadcast.

Para onde olhar

Se sua equipe está avaliando LiveView, htmx, Hotwire ou Blazor, esta é a semana certa para escrever uma ADR de adoção — com critérios objetivos (latência exigida, nº de conexões, SEO, tamanho do time, infra) e uma matriz comparando as opções em vez de seguir a moda. No nosso marketplace já tem um pacote de 5 arquivos exatamente para isso, com o schema de ADR, guardrails anti-hype e casos de teste.

Resumo do dia: o retorno do HTML ao servidor reacendeu um dos debates mais saudáveis de arquitetura — server-driven UI vs SPA — e mostrou que a escolha certa quase nunca é "tudo de um lado", mas uma decisão documentada por critérios, não por tendência.