I had a lovely time at the Keeping It Realtime Conference this week in Portland. The conference was put on by the lovely folks over at &yet and I'm glad I met them. "KRTConf" was a whole conference dedicated to "real-time" web applications. This largely meant node but also other real-time frameworks including Damien and David's SignalR that Paul Batum (Paul owns Web Sockets for .NET) and I presented. I'll blog our demo soon.
Some folks in the audience wanted to make a real-time app today but really wanted to use Web Sockets today and had concerns about broad support. Coincidentally, I had just visited &yet's new site for product called "&!" or "AndBang," a collaboration tool for teams. However, when I visited the page I got this message: https://andbang.com/you-need-websockets-yo.
In the near future, all browsers and servers will support Web Sockets, a technique by which a persistent connection is negotiated over HTTP and then a protocol switch happens from http:// to ws://. However, not every browser or server is there yet (IE9, for example) and there's some arguing about versioning, etc. If you don't support Web Sockets, falling back to "Long Polling" is a way to get effectively the same behavior that works everywhere.
Long polling is a technique that lets it look like your browser has a "persistent connection" to the server when in fact you've just got a really "persistent client." By this I mean, rather than a connection that doesn't shut down (persistent) you have a client that will make a call and when it completes, it'll call back. The very definition of persistent, eh? See what I did there?
Persistent: Continuing firmly or obstinately in a course of action in spite of difficulty or opposition.
Long Polling is not as efficient but it works nicely and is a totally reasonable fallback when Web Sockets support is unavailable. The latest preview release of IE10 includes WebSockets support. But my mom doesn't know about Web Sockets and shouldn't have to.
The 10,000 people on the planet that care about Web Sockets are not your customers, and while using Web Sockets might get you mentioned on TechCrunch, supporting only Web Sockets is a great way to cut your potential audience in half.
You can use the lovely CanIUse web site to find out if you browser supports something you'd like to use. Here's their Web Sockets table.
Your users don't care about Web Sockets. They care about delightful sites. We use JavaScript polyfills when our browsers don't support HTML5 features we want. We use jQuery when JavaScript support is dodgy between browsers. And our web frameworks should gracefully fallback to use Long Polling when Web Sockets isn't available.
Related Links
- Getting Started with WebSockets in .NET
- Asynchronous scalable web applications with real-time persistent long-running connections with SignalR
P.S. Yes, if your app is a real-time trading app or and needs down-to-the-millisecond timing, then sure, maybe you need Web Sockets. But your app isn't that app.
© 2011 Scott Hanselman. All rights reserved.