HTML sobre WebSockets: SPAs em tempo real com quase nenhum JavaScript
Enviar HTML renderizado no servidor por WebSockets como forma de construir single-page apps em tempo real com quase nenhum JavaScript está gerando debate entre desenvolvedores web. Os defensores dizem que isso simplifica o gerenciamento de estado, evita APIs complexas no cliente e pode superar SPAs tradicionais em muitos aplicativos CRUD e ferramentas internas, especialmente quando combinado com frameworks como LiveView, Hotwire, htmx ou Datastar. Os críticos respondem que HTTP/2+SSE muitas vezes alcança latência semelhante com menos riscos operacionais, que o estado de sessão mantido no servidor complica escalabilidade e cache, e que a indústria já se afastou repetidamente de renderização fortemente acoplada do lado do servidor por boas razões.
Reação geral a HTML sobre WebSockets
- Muitos veem isso como “MPA com passos extras” ou uma reinvenção de padrões antigos (DHTML, WebForms, Meteor, ASP.NET Ajax, JSF Ajax).
- Os defensores argumentam que entrega “90% dos benefícios de uma SPA com 10% do código”: atualizações em tempo real, sem API JSON separada, e o servidor como única fonte da verdade.
- Os críticos se preocupam com a redundância em relação ao HTML renderizado no servidor, a infraestrutura e os modos de falha adicionais, e o fato de firewalls corporativos às vezes bloquearem WebSockets.
Comparações: WebSockets vs SSE vs HTTP
- Vários argumentam que, para a maioria dos aplicativos, SSE +
fetch()é mais simples, mais fácil de operar e bom o suficiente para atualizações em tempo real “somente push”. - Outros contrapõem que a latência não é equivalente, especialmente em HTTP/1, e que WebSockets oferecem mensagens com ordem garantida e protocolos bidirecionais úteis para chat, jogos e fluxos de eventos complexos.
- Limitações do SSE apontadas: apenas texto, sem ordem garantida, limites de conexão por origem em HTTP/1.
- A discussão aborda HTTP/2/3 multiplexação e QUIC, e alguns mencionam WebTransport como uma opção mais nova e de menor latência.
Frameworks existentes e trabalhos anteriores
- Vários frameworks são citados como já fazendo “HTML over the wire”: Rails Turbo/Hotwire, Phoenix LiveView, Blazor Server, HTMX, Datastar, Laravel Livewire, Symfony Live Components, Inertia.js.
- Uma explicação detalhada de Turbo frames/streams mostra como atualizações parciais e broadcasts iniciados pelo servidor funcionam com JS mínimo.
- Alguns argumentam que SSE + morphing de DOM no estilo Datastar/HTMX já oferece benefícios semelhantes sem WebSockets.
Arquitetura, estado e REST
- Debate sobre se essa abordagem é “RESTless”: estado do servidor por conexão conflita com a ausência de estado do REST, mas simplifica a programação para muitas ferramentas internas.
- Os defensores gostam de que todo estado autoritativo permaneça no servidor, evitando desencontro de estado entre cliente e servidor e reduzindo pela metade o código em comparação com SPAs.
- Os céticos destacam escalabilidade, balanceamento de carga, risco de DoS e complexidade de monitoramento para conexões de longa duração.
Trade-offs de experiência do desenvolvedor e UX
- Muitos apreciam evitar grandes bundles de JS e pipelines de build; outros preferem modelos de dados-como-fonte-da-verdade em SPAs (por exemplo, Vue/React com schemas tipados).
- Reclamações sobre efeitos colaterais da substituição do DOM (perda de foco, saltos de rolagem); bibliotecas como idiomorph/Datastar tentam mitigar isso, mas adicionam infraestrutura.
- A percepção geral é que esse modelo funciona melhor para painéis administrativos, ferramentas internas e aplicativos moderadamente interativos, e menos para UIs de consumo altamente reativas.
Meta: controvérsia sobre autoria por IA
- Um artigo de acompanhamento na mesma “saga” é acusado por vários comentaristas de ter sido gerado por IA; o autor rebate.
- Isso desencadeia uma discussão paralela sobre normas de divulgação de IA generativa, desconfiança dos leitores e o impacto na autenticidade percebida da escrita técnica.