Real-time web architecture debate: WebSockets vs. SSE vs. just HTML

A post on HTML over WebSockets for real-time SPAs drew a predictably sharp response. Several commenters called it an over-engineered MPA, while the more measured replies broke down an actual useful heuristic: WebSockets for bidirectional low-latency use cases like chat or collaboration, SSE for server-push-only patterns, and plain HTML for everything else. The thread became a de facto architecture decision guide.

The pattern here is that developers keep rediscovering the same tradeoffs. Every few months a post surfaces that proposes pushing more logic through a persistent connection, and the community reliably splits between 'this is elegant' and 'just make a normal website.' The fact that this debate recurs suggests the default mental model for real-time web apps is still poorly calibrated.

The strongest signal from the thread is the SSE recommendation for one-way server push. SSE is consistently underused relative to WebSockets, cheaper to operate, and simpler to reason about for the majority of real-time UI patterns that don't actually need bidirectional communication.