Scott Hanselman

Your users don't care if you use Web Sockets

November 10, 2011 Comment on this post [28] Posted in HTML5 | Musings
Sponsored By

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:

Your browser doesn't support Web Sockets, so be sad

Switching protocols from HTTP to WebSocketsIn 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 Web Sockets 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.

Table of Browsers and their support for Web Sockets

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

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.

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
November 10, 2011 0:55
summary: Yes I know IE is holding back the entire intarwebz. Tough. If you don't want to piss off half of your users then suck it up and do more work.
November 10, 2011 0:57
Rush - LOL, there's no additional work. Just set a flag. SignalR supports WebSockets -> long polling fallback out of the box with no work at all. It's not rocket science on node either.
November 10, 2011 1:02
Microsoft released a WebSockets prototype for the browser based on a Silverlight shim months ago. This can serve as a great fallback, you could also fallback on a Flash shim though.

For those who are interested, I wrote about the MS prototype internals here.

Scott, you might also want to mention the MS HTML5 Labs site.
November 10, 2011 1:28
Before Node.js and, I would embed a hidden Flash file on the page and use JavaScript to communicate with ActionScript Sockets. While I'm glad there is finally a browser standard for sockets, it's not impossible to do it without HTML5 WebSockets.

One issue that I've personally come across is that makes WebSockets so easy to produce and consume that I want to use it everywhere. Unfortunately, not every language has a WebSocket library, let alone one that understands the protocol. I recently had to add support for in a Java WebSocket library for use on Android. ( Then I'll have to do the same thing in Objective-C for iOS...
November 10, 2011 1:44
In principle, when discussing most websites, I'd agree with you. But this &! thing doesn't look like it's just "some website", it's a commercial tool which just happens to be delivered over a web interface.

To me, not supporting all browsers on a product like that feels less like putting up a website that cuts out half your audience, and more like selling a software package which doesn't support every OS platform. And nobody ever thought that was so unusual, did they? If you release software that only runs on Windows, not Mac or Linux, some people will be unhappy, but surely the response will be a shrug and an "I guess that segment of the market didn't justify the extra development time and expense".
November 10, 2011 3:42
I wonder how large the intersection of IE users and &!'s target audience really is though? It doesn't seem to be aimed at someone running IE because they don't know any better, nor the corporate user that's stuck on IE due to IT policy.
November 10, 2011 5:19
Sites that do this are trying to show off some kind of non-IE support superiority complex. It's tired.
November 10, 2011 8:52
This has nothing to do with IE one way or the other. When IE 10 comes out and supports Websockets, we'll be happy to support IE. We're just early adopters of a spec.
November 10, 2011 9:06
I agree with Chris, sites like that totally turn me off. If you don't want to support my choice of modern web browser (within reason of course) then I choose not to support your site. Thank you and goodbye.
November 10, 2011 9:12
Hmm... I thought the idea behind it is too *push* IE so that IE vNext (yes, IE10 and beyond) would support web sockets. And I guess not caring the users (*for awhile* until MS release IE vNext with web sockets support, or just simply switch to other browsers which support it if they couldn't wait for it) is a reasonable price to pay :D

Also, I think the links provided referring to other browsers says something like this, "Your browser (IE) doesn't support it. If you want to experience a full experience of the web, please use these browsers instead: Chrome, Firefox, and Safari." And that would hurt IE market share (if MS still care about it :D)

In other words, the message sent is directed to MS, not the users.

So, when IE10 will be released?
November 10, 2011 9:17
This is an excellent post, and I don't mean to take away from it at all. But one thing bothers me -- it's been niggling at me for a couple of years, since I first saw Joel Spolsky doing it on his site. It's the use, or misuse, of this word 'delightful'. There is something creepy and Newspeak about the way it's infiltrated tech blogs. I thought the height of absurdity was when I saw it used in connection with cruise missiles. Apparently the goal of defense contractors is to build missiles that 'delight' their customers. Let's back up a step here. Missiles may be accurate, damaging, terrifying and even 'smart', but 'delightful' is kind of a perverse word to use in this context. And while it's not really perverse to talk about 'delightful' web sites -- or maybe it is! -- it still seems like an greasy and ill-fitting term. It's slippery. It doesn't grip the subject tightly.
November 10, 2011 9:35
Iian - Wasn't thinking about Joel, rather meant it in the purest sense as in "full of delight" but still, point taken.

Maximilian - No idea.
November 10, 2011 10:09
I found this MVC chat app a good starting point for some .net long polling:

Does the MVC equiv of async pages so that the waiting threads don't blow up your server.
November 10, 2011 14:04
"...but that app isn't your app."

Yes it is! I used to work on a web based trading app. And quite rightly, we had a family of different connection modes that could be arranged in a fallback sequence to support just about any web browser. WebSockets was purely experimental at the time, but different browsers favour different methods for comet-style push communication so we always had the best way for each mainstream browser, even IE6.
November 10, 2011 18:48
Hey Scott, great article. We've been working with real-time tech on the Microsoft stack for quite some time @ Frozen Mountain with WebSync (our comet solution), and you've noted exactly what we've found - for 90% of the scenarios out there, WebSockets simply isn't necessary, and a long-polling solution works just fine. I mean, I'm excited about WebSockets (real-time gaming in the browser, here we come!) but it's not as "necessary" as it's made out to be.

Anyway - I'd also love your feedback on WebSync ( There are a few really awesome things about it, IMHO ;) 1) Lots of client support (JavaScript [of course], iOS, Java [Android], Windows Phone, standard .NET, and so on; 2) a very "Aspect Oriented" design approach to integrating custom logic; 3) great support for server clusters. Anyway, if you have time to check it out, I'd welcome your thoughts!
November 11, 2011 0:55
Aren't HTML and Javascript delightful?
November 11, 2011 1:27
The saccharine chirpiness of their site is so sickly to the point of it almost being a parody. "Netscape Now!" anyone?
November 11, 2011 2:59
I think the point is, though, that people making SignalR and had to make long polling primarily because I.E. is significantly behind the curve.

Innovation is slowed slightly because the folks making those toolkits could've been doing other stuff rather than making workarounds for I.E.

And think about how much time was wasted in the 6-7 years or so working around IE6. I know the last few places I've worked out I've spent significant amounts of time dealing with IE6 backwards compatibility and even opted not to do certain features simply because supporting IE6 was too expensive.

IE9 isn't as bad as IE6, but it's still behind the curve in many respects and IE is still holding things back to some extent.
November 12, 2011 7:52
@Chad Myers your point runs afoul of the reality that not everyone is going to adopt new technology as soon as those who read tech blogs do.

I added a simple SignalR chat to a website where the users squeak by with tech. These are a group of people who then struggled with the concept of using text based commands in the chat. At least a third of these people could not set up a gravatar or use the basic </commands> to enter the chat room (even when instructions on how to do so was given on the page. Eventually, I had to rewrite the client to step people individually though the setup.

Let's us say that next quarter (when I'm assumeing IE 10 will be out) there will still be millions and millions of people on out of date browsers. In that case, MS will have have a solution which implements websockets *without* cutting off technological luddites.

November 14, 2011 5:35
@sgmarshall I think sockets has huge mainstream application in line-of-business apps and other enterprise data apps. That's all I did for 2 years at the Federal Government (l-o-b apps) and I would've killed for web sockets because a lot of what I did was background tasks, queuing, etc. (async stuff) and had to hack to get progress bars and such.

The reason it's not mainstream right now is because MS is holding people back with the slow pace of IE. If MS was up to date, devs (even enterprisey, captive IT) would be using it like crazy.
November 22, 2011 0:21
"The users don't care about your engine, they just want faster horses".

Of course the users don't care about web sockets, but the users don't get to make that decition... I care about web sockets because I know that when the user is asking for a faster horse, he really needs a car.
November 22, 2011 5:56
This has nothing to do with IE one way or the other. When IE 10 comes out and supports Websockets, we'll be happy to support IE. We're just early adopters of a spec.

BOSH works on close to 100% of web browsers you're likely to see, including Internet Explorer 4 and later, FireFox 1.5 and later, and all versions of Chrome and Safari -- and Android Chrome and iPad Safari to boot.

The current WebSockets draft doesn't match what FireFox, Opera, Safari and Chrome actually implement. It doesn't work on Android. It doesn't work on Internet Exploder. It doesn't play well with corporate firewalls, proxies, content filters, transparent proxies and other technologies you're likely to find in the wild. And it's hard to conceive that system administrators who are paranoid about what protocols they allow in and out of their network would ever find WebSockets to be appetizing.

It's another gift from WHAT/HTML5 WG -- the same committee that is more concerned about branding login screens than about the user knowing where the form they're about to submit is actually routed to. (sigh) Because it's not like there's a ton of phishing going on or anything.
November 22, 2011 6:09
IE is THE single most cause of grief for me as a developer. It is anchor browser defined. There is not a single project that goes by where IE turns into a show stopper, road block or insufferable time bandit. I have grown to despise it. I have never hated any piece of software before, but I truly hate IE
November 22, 2011 17:59
IE is below 50% now.

Either step up the release cycle to get more features out faster or just use someone else's browser engine. IE actually has to fight for users now and web developers are not going to bend backwards to support it. By the way IE is the only browser that doesn't support web sockets.
November 22, 2011 23:00
@Donny Velazquez - how can you say that IE is the only browser that doesn't support web sockets? Safari, Opera, Android - are all partially or not supported.
November 24, 2011 8:45
The takeaway from this article, for any product company, should be DO NOT PISS OFF HANSELMAN by telling him his browser (! HIS F* BROWSER) can't run your web app.

BTW, I couldn't agree more with the point of this. As with anything in life, if you want to remain completely pure you'll have to accept remaining pretty lonely.
November 29, 2011 2:41
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.

Websockets are just wrong for "real-time" whatever (more like html is wrong for). Still I don't quite see the downside of using 2 sockets for communication, you may pay 2sockets read/write buffers on the server + http header per request. The buffers sizes are available to setup and then it's just an extra file descriptor.

Yet, it works perfectly well over crazied corporate firewalls/proxies.

@Dave, it's more like gift from google to get their job done (incl. native client)

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.