WebSockets vs. Server-Sent-Events vs. Long-Polling vs. WebRTC vs. WebTransport

Original Article ↗ Hacker News Discussion ↗

Real‑time communication on the web is less about picking “the best” protocol and more about navigating trade‑offs between simplicity, scalability, reliability, and network quirks. Engineers compare long polling, Server‑Sent Events, WebSockets, WebRTC, and emerging options like WebTransport and HTTP/2/3 streaming, noting issues such as firewall and proxy compatibility, mobile battery impact, lack of standard backpressure, and browser limits on concurrent streams. Many favor SSE or long polling for their simplicity and tooling friendliness, while others point to WebSockets and WebTransport for higher performance—arguing that protocol choice ultimately matters less than designing robust reconnection, state recovery, and authentication patterns around it.

Long Polling & Polling Patterns

  • Some miss long polling for its simplicity and HTTP-friendliness; others argue real-world deployments show it’s not “stupidly simple” once you consider timeouts, proxies, retries, and message ordering.
  • Long polling is praised for interoperability with generic HTTP tools and APIs.
  • Several note that any push-style system needs a way to rehydrate full state and handle missed updates; at that point, plain polling or cursored “events endpoints” can be attractive.
  • Debate on scalability: one side says long polling scales linearly like other techniques; another notes extra subscription churn and RTT/packet overhead make it “least scalable” in practice.

Server-Sent Events (SSE)

  • Widely liked for simplicity, easy integration with basic stacks (e.g., Apache + PHP), and CDN-friendliness.
  • Seen as “standardized long polling/Comet” over chunked responses.
  • Limitations: text-only (binary requires base64 or special encodings), browser-imposed connection limits with HTTP/1.1, and limited header control in the native EventSource API.
  • Workarounds include HTTP/2/3 multiplexing, domain sharding, SharedWorkers/broadcast channels, and custom SSE clients with richer options.
  • Some report SSE reliability issues in locked-down/enterprise environments and with certain server frameworks.

WebSockets

  • Popular as a default for bidirectional real-time, often with JSON-RPC on top.
  • Criticisms: harder to scale and operate, lack of built-in multiplexing and backpressure (though new WebSocketStream aims to help), and ongoing firewall/corporate-network issues in some environments.
  • Many use libraries that provide fallbacks (long polling, SSE, etc.) to handle broken proxies and old browsers.

WebRTC & WebTransport

  • WebRTC works reliably in practice for NAT traversal and is widely deployed; best suited for P2P and rich media, less so for simple server push.
  • WebTransport is appreciated for streams, backpressure, and avoiding head-of-line blocking; some already use it for games.
  • Concern: UDP/HTTP/3 may be blocked on some networks, forcing dual implementations with WebSockets.

HTTP Streaming & Variants

  • Several emphasize generic HTTP response streaming (e.g., JSONL over fetch streams, HTTP-streaming transports) as a powerful, often underused option, sometimes preferred over SSE for finite streams.

Auth, Background, and Mobile

  • Browser APIs for SSE/WebSockets make custom auth headers awkward; cookies are the common workaround, or custom clients.
  • Mobile and background behavior is problematic: radios, timeouts, and worker lifetimes can break “always-on” connections; push APIs and refresh buttons remain important fallbacks.