#pubsub

Everyone defaults to WebSockets for real-time features. Most shouldn't. The reality: 95% of "real-time" applications only need server → client updates. Chat notifications. Live dashboards. Stock tickers. Log streams. AI responses. WebSockets give you bidirectional communication. But bidirectional comes with a tax: complexity, resource overhead, scaling challenges, debugging nightmares. Server-Sent Events (SSE) do one thing: stream data from server to client. They do it brilliantly. And for most applications, that's all you need.

The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin. By creating a BroadcastChannel object, you can receive any messages that are posted to it. You don't have to maintain a reference to the frames or workers you wish to communicate with: they can "subscribe" to a particular channel by constructing their own BroadcastChannel with the same name, and have bi-directional communication between all of them.

"Most people throw around the term “pub/sub” to describe any kind of eventing/messaging – but I think this term fails to adequately communicate the abstraction. Yes, ultimately, something is subscribing to what something else is publishing. But the level at which publishers and subscribers are encapsulated has the power to make a good pattern turn to the dark side. So, what’s the difference?"

"Most people throw around the term “pub/sub” to describe any kind of eventing/messaging – but I think this term fails to adequately communicate the abstraction. Yes, ultimately, something is subscribing to what something else is publishing. But the level at which publishers and subscribers are encapsulated has the power to make a good pattern turn to the dark side. So, what’s the difference?"