Server-Sent Events (SSE) Are Underrated

Use cases and libraries

  • Used for streaming hypermedia UIs, chatbots/LLMs, log tailing, hot reloading, and CLI “auto-restart on config change”.
  • Several dedicated systems built around SSE: frontend frameworks, pub/sub hubs, and realtime servers that support multiple transports (SSE, HTTP streaming, WebSockets, gRPC).
  • SSE often chosen when only server→client updates are needed, especially in stacks where WebSockets are heavier to integrate.

Perceived advantages

  • Very simple to set up on the server; often “a few lines” in common web frameworks.
  • Browser EventSource API provides automatic reconnection and ID-based resumption.
  • Plays well with HTTP/2 and HTTP/3, giving efficient multiplexing and avoiding connection limits.
  • Often works better than WebSockets through corporate proxies/firewalls and some network middleboxes.
  • More bandwidth- and battery-efficient than polling, since it avoids repeated HTTP headers and connections.

Major limitations and ecosystem issues

  • On HTTP/1.1, browsers cap open SSE connections per origin (~6), causing failures with many tabs; no clean client-side way to detect hitting the limit.
  • Some corporate networks downgrade or MITM TLS and only support HTTP/1.1, breaking the “just use HTTP/2” fix.
  • Some load balancers, proxies, tunnels, and FaaS platforms buffer or time out long-lived HTTP responses, making SSE unreliable unless tuned (pings, timeouts, flush behavior).
  • No binary framing; everything is text. Newline-based framing and the data: prefix can conflict with raw text payloads, requiring encoding and robust parsers.
  • Native browser EventSource lacks Authorization header support, pushing people to polyfills or custom streaming clients.
  • Mobile/background behavior and battery cost of frequent pings are problematic and not fully resolved.

Patterns and workarounds

  • Use a single SSE connection per origin and multiplex logical channels over it.
  • Coordinate multiple tabs via BroadcastChannel or Web Locks; possibly centralize the SSE connection in a worker.
  • Some prefer generic HTTP streaming with ReadableStream and custom length-prefixed or ndjson framing over SSE’s fixed format.

SSE vs WebSockets

  • Supporters argue SSE is simpler, more compatible with existing HTTP infra, and good enough for unidirectional updates.
  • Skeptics argue WebSockets are ubiquitous, easy to constrain to one direction, and that SSE’s edge cases (infra quirks, framing, limits) reduce its appeal.