All About The HTML BroadcastChannel API

The only browser to support the BroadcastChannel API is Firefox 38 (at the time of writing this) which isn’t slated for release until May, 2015. If you are using Firefox Developer Edition, then you already have support for the BroadcastChannel API and you can start playing around with it now.

This new API opens up a world of possibilities, working around inherent limitations in the existing postMessage API we already have. The BroadcastChannel API is part of the WHATWG living HTML standard which can be seen here.

Lets go into specifics and talk about what this new API actually is and how it can benefit us.

What is the BroadcastChannel API?

The BroadcastChannel API allows communication between all windows, iFrames and anything else on the same origin domain and user agent. Meaning if the user has two tabs for the same website open when something changes all windows can be notified.

Still lost? Take Facebook as an example. Say you have a window already open on Facebook but you’re not logged in and then you open up another and login, you can notify the other tabs/windows that a user has logged in and refresh.

Essentially the BroadcastChannel API allows us to create state aware applications without needing to use sockets or timers to achieve the same thing. Effectively it’s a publisher/subscriber system for the browser.

BroadcastChannel API in action

Creating a new BroadcastChannel

Creating a new BroadcastChannel is simple enough. Pass in the channel name as the argument to the BroadcastChannel constructor and save its reference to a variable.

let cast = new BroadcastChannel('mychannel');

Sending a message

Sending a message is as simple as referencing the variable containing the BroadcastChannel instance (in our case it’s “cast”), then call the postMessage method.

If you’re familiar with other publisher/subscriber based systems, the postMessage method might also make more sense to you if you refer to it as an even emitter.

The beautiful thing about the postMessage method is that you can send anything. An object, a string or whatever. As long as the subscribers are aware of what the event will emit, go to town.

myObj = {someKey: 'Some value', anotherKey: 'Another value'};
cast.postMessage(myObj);

Unlike some more fully-fleshed pub/sub systems, there is no native implementation support for topics. Meaning you cannot have a channel and then broadcast particular topics that subscribers can listen too.

However, through some creative coding you can mock this kind of implementation by using objects and sending the topic as a key on the object and the data as a key “data”.

Listening to messages

Or more commonly known as subscribers. A receiver will listen to a postMessage event fired on our BroadcastChannel channel reference defined earlier for the particular channel.

cast.onmessage = function (e) { 
    console.log(e); // This should print out the contents of the object we sent above
}

Disconnecting

Presumably you care about Javascript performance and you are mindful of the resources you are using (especially on mobile). Luckily there is a method in-built for closing connections inside of a BroadcastChannel.

cast.close(); // Close our connection and let the garbage collection free up the memory that was used

Browser support

As mentioned above, currently Firefox version 38 only supports the BroadcastChannel API (or Firefox Developer Edition). Presumably, other browsers will hopefully follow with support shortly because it is definitely a useful API. From stateful applications to games, really the sky is the limit here (followed closely by browser support).

Keep in mind, support is basically non-existent from a consumerist perspective. However, there is a polyfill which lets you use BroadcastChannel API functionality now. Keep in mind it is really no substitute for the real implementation which hopefully lands soon.

Conclusion

The future is bright, man. While we cannot use BroadcastChannel API in our applications properly just yet, in the not too distant future we will. Thanks to the living HTML standard, we now have a way of cross-context communication without needing to know the exact context like existing and limited implementations.