What are server-sent events?

SSE is a one-way stream from server to browser over an ordinary HTTP connection that stays open. The server pushes messages whenever it has them; the client just listens.

const source = new EventSource("/api/updates");

source.addEventListener("message", (e) => console.log(e.data));
source.addEventListener("price", (e) => update(JSON.parse(e.data)));  // named event
source.addEventListener("error", () => { /* it will retry by itself */ });

source.close();

The server responds with Content-Type: text/event-stream and writes a simple line format:

event: price
data: {"symbol":"ABC","value":42}

Each message ends with a blank line. That is the whole protocol.

Why choose it over WebSocket

• Automatic reconnection. If the connection drops, the browser retries on its own and sends a Last-Event-ID header so the server can resume — you get for free what WebSocket makes you build.
• Plain HTTP. It works through proxies and firewalls, uses your existing auth and cookies, and needs no special server.
• Simpler on both ends.

When WebSocket is the right choice instead

SSE is server to client only. If the client needs to send frequent messages — chat, collaborative editing, games — you need the two-way channel. For SSE, client messages go over normal requests, which is fine when they are occasional.

SSE also carries text only; binary needs encoding.

One real limitation

Over HTTP/1.1, browsers cap connections at about six per domain, and each open EventSource consumes one. Several tabs can exhaust the budget and block other requests. HTTP/2 multiplexing removes this, so check your stack before relying on many streams.

Good fits: notifications, live dashboards, progress for a long job, a feed of updates — anywhere data flows one way and you would otherwise be polling.