Server-sent events

Server-sent events make client-side interactivity based on server-side events trivial to implement: no more websocket servers.

Ryan Florence posted this tweet the other day, showing real-time updates in Remix, and I thought at first that he'd built some slick websockets stuff into Remix. Alright, that's pretty cool. But it's not websockets.

It's server-sent events.

Websockets are terrific for opening and persisting a connection with a server that you're going to regularly communicate with. You send data up the line, and data comes back down the line to you. It's two-way.

Server-sent events, on the other hand, only send data down to the client (the browser). As the name implies, the server can't receive events—only send them, over an open HTTP connection. But for 80% of use cases, that's fine[1].

The benefit of this is that you don't have to spool up a whole nother server just to handle the websocket connections. It's all just HTTP, using some clever Content-Type headers. This makes client-side interactivity based on server-side events trivial to implement—another way that traditional "multipage" applications are closing the gap to single-page applications.

Server-sent events, MDN

Web Code Browser


On Mastodon

I'm on Mastodon, and I quite like it.


Sustainable web development

Sustainable web development doesn't just mean using best practices.