Your users don't care if you use Web Sockets
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 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.
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.
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.
About Newsletter
rushonerok
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.
One issue that I've personally come across is that socket.io 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 socket.io protocol. I recently had to add support for socket.io in a Java WebSocket library for use on Android. (https://github.com/jinushaun/java-socket.io.client) Then I'll have to do the same thing in Objective-C for iOS...
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".
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?
Maximilian - No idea.
Does the MVC equiv of async pages so that the waiting threads don't blow up your server.
"...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.
Anyway - I'd also love your feedback on WebSync (www.frozenmountain.com/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!
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.
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.
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.
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.
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.
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.
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.
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.