I spent most of last year defaulting to WebSockets for anything that needed updates in real time. A new order came in, a price ticked, a job status changed. WebSocket. Two months ago I was building a small monitoring dashboard for a Laravel app. I wired up a WebSocket server, added a client library, added reconnection logic, added ping\/pong handling, added the whole thing, and then paused and asked what I was actually doing. The dashboard only needed the server to push updates. The client had nothing useful to say back.<\/p>\n
I ripped out the WebSocket setup, wrote about twelve lines of Server-Sent Events, and shipped it that afternoon. It’s still running. Nothing broke. Nothing needed a reconnection library. I felt a little dumb, in a good way.<\/p>\n
So here’s my honest take on when to pick which in 2026, based on shipping a bunch of these across Laravel, Node, and a Rust axum service.<\/p>\n
Does the client need to send anything meaningful back?<\/p>\n
If yes, WebSockets. Chat rooms, collaborative editors, multiplayer games, terminals. You need bidirectional traffic, so use the tool built for that.<\/p>\n
If no, SSE. Dashboards, feeds, LLM token streams, notifications, progress bars, log tails. The server pushes, the client listens.<\/p>\n
That’s the whole decision. Everything else is optimization detail. I’ve watched teams tie themselves in knots over “what if we might need bidirectional later?” You know what SSE has for that? A regular HTTP POST to a different endpoint. Same server, same auth, same middleware stack. Browsers turn out to be pretty good at making HTTP requests.<\/p>\n
Here’s the shape of it in Node with Express, which is where most people meet it first:<\/p>\n
app.get("\/events", (req, res) => {\n res.set({\n "Content-Type": "text\/event-stream",\n "Cache-Control": "no-cache",\n "Connection": "keep-alive",\n "X-Accel-Buffering": "no",\n });\n res.flushHeaders();\n\n const send = (data) => res.write(`data: ${JSON.stringify(data)}\\n\\n`);\n const interval = setInterval(() => send({ ts: Date.now() }), 1000);\n\n req.on("close", () => clearInterval(interval));\n});\n<\/code><\/pre>\nAnd the client:<\/p>\n
const es = new EventSource("\/events");\nes.onmessage = (e) => console.log(JSON.parse(e.data));\n<\/code><\/pre>\nThat’s a functioning real-time channel. No handshake protocol, no ping frames, no library. The browser handles reconnection automatically, and if you set an id:<\/code> on your events it will send Last-Event-ID<\/code> back on reconnect so you can resume cleanly. It’s closer to reading a slow file than to doing networking.<\/p>\nFor comparison, the equivalent WebSocket setup means picking a library (ws, socket.io, uWebSockets), configuring a server, handling upgrade requests, defining your message format, implementing ping\/pong, deciding on JSON or MessagePack, wiring auth through a different path than the rest of your HTTP stack. All of that is fine and worth it when you actually need it. It’s not fine when you don’t.<\/p>\n
When WebSockets earn their keep<\/h2>\n
I still reach for WebSockets when the client is producing events at unpredictable intervals, not just consuming them. Chat is the obvious example. Cursors in a shared doc, live audio metadata, IoT telemetry from a device. If the traffic pattern is bursty and I want a single long-lived connection rather than the client re-opening streams, that’s a WebSocket job too. Games. Trading UIs.<\/p>\n
Binary transport is another clean split. SSE is text-only, per the spec. If you’re streaming Protobuf frames or audio chunks, WebSockets. And if latency on the return path really matters, yes, a POST also works in theory, but at 60 messages per second in either direction you want the connection you already have.<\/p>\n
For the Laravel side of this, I wrote about swapping Pusher for Laravel Reverb<\/a>, which is a legitimate WebSocket use case: broadcasts, presence, both directions.<\/p>\nThe scaling story most tutorials skip<\/h2>\n
The thing that trips up almost everyone with SSE is this: browsers cap HTTP\/1.1 connections to six per origin.<\/strong><\/p>\nIf your site opens an SSE stream on \/events<\/code> and the user opens six tabs, tab seven can’t open a new stream. It just hangs. This is not an SSE-specific problem, it’s an HTTP\/1.1 problem, but SSE makes you notice it because you’re holding the connection open indefinitely.<\/p>\nTwo fixes:<\/p>\n
\n- Serve SSE over HTTP\/2 or HTTP\/3. The per-origin cap stops mattering because HTTP\/2 multiplexes many streams over one TCP connection. This is the default answer in 2026. If you’re behind Nginx, Cloudflare, or Vercel, you probably already have HTTP\/2 in front of the browser.<\/li>\n
- Put SSE on a subdomain like
events.yourapp.com<\/code> so it has its own connection budget. Useful when you can’t control the edge proxy.<\/li>\n<\/ol>\nThe other thing that surprises people is proxy buffering. Nginx will happily hold your SSE payload in memory until it feels like flushing. Setting X-Accel-Buffering: no<\/code> on the response tells it to stop. Most CDNs have a similar knob.<\/p>\nWebSockets have a different pain: some corporate proxies still don’t like the Upgrade dance and will kill the connection. SSE looks like a normal HTTP response with a text\/event-stream<\/code> MIME type, so it slips through almost everywhere. That’s a legitimate reason to prefer SSE inside enterprise networks.<\/p>\nLLMs quietly made SSE the default for AI streaming<\/h2>\n
Every LLM API I use ships tokens over SSE. OpenAI. Anthropic. The local vLLM endpoint I run on a workstation. Not WebSockets. That’s not accidental. Token streaming is server-push. The client sends one request and reads. It’s the natural fit. The WHATWG SSE spec<\/a> shows how boringly small the wire format actually is: data:<\/code> lines terminated by a blank line, optional id:<\/code> and event:<\/code> fields, done.<\/p>\nWhen I’m building the frontend for something that talks to an LLM, I use the browser’s EventSource<\/code> for anonymous streams or a fetch-based reader when I need auth headers. EventSource<\/code> famously does not support custom headers, which is a real limitation to know before committing. If you’re building AI features on top of a Node backend, most SDKs already return an async iterator over the SSE stream. The MDN Server-Sent Events guide<\/a> covers the client side well.<\/p>\nFor type-safe streaming APIs I’ve been reaching for the same shape I described in my tRPC post<\/a>: a subscription with a server iterator that maps neatly onto an SSE response.<\/p>\nThe rough rules I keep on a sticky note<\/h2>\n
Bidirectional traffic from the client? WebSocket. Binary payloads? WebSocket. Enterprise proxies in the path? SSE. LLM tokens? SSE. Anything I could implement over polling but want smoother? SSE. Want to reuse existing HTTP auth, cookies, middleware, and rate limiters without rethinking any of it? SSE. Team already runs Redis pub\/sub or Kafka and needs a fanout channel to browsers? Either. That decision goes back to the front-half question about who’s talking.<\/p>\n
The failure mode I want to warn against is reflexive-WebSocket. It happens because the WebSocket ecosystem is louder. There are more libraries, more conference talks, more “real-time” branding on the marketing pages. SSE has been sitting in the browser since 2011 and gets almost no attention. It’s fine to feel like you’re picking the boring option. You are. That’s the point.<\/p>\n
If you want to see how these show up in real projects I’ve built, most of the client work I do around real-time features lives in my project work<\/a>.<\/p>\nTry this next week<\/h2>\n
Pick one WebSocket endpoint you already have that only pushes to the client. Rewrite it as SSE. See if the code shrinks. See if anything actually breaks. If nothing does, that’s the new default for that shape of feature.<\/p>\n