Cross-Document Communication With The Broadcast Channel API In JavaScript

The browser has long had the window.postMessage() API, which gave us the ability to post messages across window contexts; and across origins. This provided flexibility but also incurred a number of security burdens. The Broadcast Channel API is a more focused, more secure version of the .postMessages() API.

The Broadcast Channel API also allows us to post messages across browser tabs without having to have a target reference. One limitation of the window.postMessage() API is that you needed a window reference (or something akin to window.parent, window.opened) in order to know who you were posting messages to. The Broadcast Channel API, on the other hand, can effortlessly publish messages to any subscriber of a given channel in any window or tab in the same origin.

The Broadcast Channel API doesn’t wholly replace window.postMessage(); but, it does feel like a nicer fit for any cross-tab communication that can happen within the bounds of a domain.

The Broadcast Channel API is rather small and easy to use. You just instantiate an instance of the BroadcastChannel(name) constructor and either send messages with .postMessage() or listen for messages via the message event. To demonstrate, I’ve created a top-level page with 6 elements. Each of the frames is loading the same page. And, each of the frames both announces local mouse coordinates and mirrors mouse coordinates emitted from one of the other frames.

The mouse coordinates are represented as a laser pointer dot. So as you move the mouse across the frames, the laser pointer dot should move to the same relative location within each frame.

Within the frame, I’m creating a BroadcastChannel() instance with the name pewpew. I then send and receive messages with a .type = lasermove discriminator property. Example:

channel.postMessage({
	type: "lasermove",
	clientX: 100,
	clientY: 75,
});

This was a personal choice. I could have just as easily created a broadcast channel with the name, lasermove, and then not include any discriminator property at all.

I don’t have an instinct yet for which approach makes more sense. Is it better to have one big communication pipe with lots of different message types? Or is it better to have lots of little communication pipes each with a single message type? Or something in between. No idea.

That said, the code for this demo is straightforward. I’m listening to the mousemove event and then broadcasting the clientX/clientY coordinates. The laser pointer dot is implemented as a fixed-position element:

If I run this demo and then move my mouse across the frames, I get the following output:

As you can see, when I move the mouse across one iframe, the relative location of that mouse is mirror across the other 5 iframe elements.

Note that the frame that broadcasts the event also has to explicitly position the laser pointer dot within its own frame. That’s because events are not echoed back to the broadcaster.