Register for this year’s #ChromeDevSummit happening on Nov. 11-12 in San Francisco to learn about the latest features and tools coming to the Web. Request an invite on the Chrome Dev Summit 2019 website

BroadcastChannel API: A Message Bus for the Web

The BroadcastChannel API allows same-origin scripts to send messages to other browsing contexts. It can be thought of as a simple message bus that allows pub/sub semantics between windows/tabs, iframes, web workers, and service workers.

API basics

The Broadcast Channel API is a simple API that makes communicating between browsing contexts easier. That is, communicating between windows/tabs, iframes, web workers, and service workers. Messages which are posted to a given channel are delivered to all listeners of that channel.

The BroadcastChannel constructor takes a single parameter: the name of a channel.
The name identifies the channel and lives across browsing contexts.

A channel won't broadcast to itself. So if you have an onmessage listener
on the same page as a postMessage() to the same channel, that message event
doesn't fire.

Differences with other techniques

At this point you might be wondering how this relates to other techniques for message passing like WebSockets, SharedWorkers, the MessageChannel API, and window.postMessage(). The Broadcast Channel API doesn't replace these APIs. Each serves a purpose. The Broadcast Channel API is meant for easy one-to-many communication between scripts on the same origin.

Some use cases for broadcast channels:

Detect user actions in other tabs

Know when a user logs into an account in another window/tab.

Instruct a worker to perform some background work

Know when a service is done performing some action.

When the user uploads a photo in one window, pass it around to other open pages.

Example - page that knows when the user logs out, even from another open tab on the same site:

In another example, let's say you wanted to instruct a service worker to remove
cached content after the user changes their "offline storage setting" in your app.
You could delete their caches using window.caches, but the service worker may
already contain a utility to do this. We can use the Broadcast Channel API to
reuse that code! Without the Broadcast Channel API, you'd have to loop over the results of self.clients.matchAll() and call postMessage() on each client in order to achieve the communication from a service worker to all of its clients (actual code that does that). Using a Broadcast Channel makes this O(1) instead of O(N).

Example - instruct a service worker to remove a cache, reusing its internal utility methods.

window.postMessage() also allows you to communicate across origins. The Broadcast Channel API is same-origin. Since messages are guaranteed to come from the same origin, there's no need to validate them like we used to with window.postMessage():

Simply "subscribe" to particular channel and have secure, bidirectional communication!

Difference with SharedWorkers

Use BroadcastChannel for simple cases where you need to send message to potentially several windows/tabs, or workers.

For fancier use cases like managing locks, shared state, synchronizing resources between a server and multiple clients, or sharing a WebSocket connection with a remote host, shared workers are the most appropriate solution.

Difference with MessageChannel API

The main difference between the Channel Messaging API and BroadcastChannel is that the latter is a means to dispatch messages to multiple listeners (one-to-many). MessageChannel is meant for one-to-one communication directly between scripts. It's also more involved, requiring you to setup channels with a port on each end.