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

Original Article ↗ Hacker News Discussion ↗

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.