Why BrowserChannel?03 Apr 2012
After the release of clj-browserchannel-demo, I have been asked what BrowserChannel is exactly. This post will hopefully clarify what BrowserChannel is and why it is a great fit for ClojureScript and Clojure web applications.
BrowserChannel is a protocol developed by Google. It provides cross-browser compatible, real-time, bi-directional communication for various Google web apps, including Google Docs and GMail.
An important part of this definition is the bi-directional communication. The client can send messages to the server and the server can send messages to the client. Canonical examples that require these types of communication are chat applications and stock/news tickers. In a chat app the client can send something to the server and whenever somebody else says something this needs to be pushed to all the clients. A stock ticker might not need the client to send stuff to the server, but the server needs to be able to constantly push messages to the client. This bi-directional communication is more elaborate than just AJAX request that don't need a page refresh. An example of uni-directional client->server communication is the ClojureScriptOne example application.
Similar bi-directional communication functionality is provided by Comet libraries, Socket.io, Sock.js and WebSockets.
WebSockets will ultimately replace BrowserChannel completely, as it serves the exact same purpose. But WebSockets is under heavy development and constant change. Therefore very few clients properly support WebSockets. BrowserChannel delivers the functionality right now, with support on almost every client imaginable, including Internet Explorer 5.5+. I know of only one shop that used WebSockets in production and they dropped support for WebSockets after users reported problems, mostly behind firewalls.
BrowserChannel is a pragmatic alternative to WebSockets that works on many clients today:
- XHR connections or forever iframes for Internet Explorer
- Both in streaming and non-streaming versions
- Explicit testing for buffering problems on the connection
- Cross domain possible by using XPC
- Work around for connection limits to the same domain
The cost over WebSockets is the overhead of requiring more requests between the client and server.
Of course the question is if BrowserChannel is production ready: open firebug, goto gmail.com and look for the GET and POST requests to /channel/test?VER=8 and /channel/bind?VER=8:
For further information see the README of the clj-browserchannel-demo project on GitHub. The demo runs on Heroku: BrowserChannel app