Why I Still Reach for Server-Sent Events

Whenever a project needs "live updates," the default instinct is to reach for WebSockets. They’re powerful, bidirectional, and well-supported — and for a lot of use cases, they’re more than what’s actually needed.

Server-Sent Events cover a surprising amount of ground: a plain HTTP connection the server keeps open and streams text down. No separate protocol handshake, no extra library on the client — just an EventSource and a route that writes to the response as data becomes available. Browsers reconnect automatically if the connection drops, which is one less thing to build.

The tradeoff is obvious: it’s one-directional. The client can’t push messages back over the same connection. For dashboards, notifications, and progress streams — anything where the server is the one with news to share — that constraint is barely a constraint at all, and the resulting code is a fraction of the size of a WebSocket setup.

I used this pattern for a small hello-world streaming demo on this site, and it’s the same shape I’d reach for on a production dashboard: simple until proven insufficient.