Why BrowserChannel?
03 Apr 2012After 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.
For ClojureScript and Clojure web apps that need bi-directional communication BrowserChannel is a good fit. The client side part of BrowserChannel is part of the Google Closure Library and ClojureScript leverages the Google Closure compiler and library extensively already. In the clj-browserchannel-demo this good fit shows by the few lines of ClojureScript that are required. There are no external JavaScript dependencies besides the Closure library. The server side portion of BrowserChannel has not been open-sourced. clj-browserchannel-demo fills this hole with an implementation in Clojure.
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.
The punchline
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