At Review19 - http://review19.com - we are primarily using web sockets but we have fallback / failover transports in place.

What helps is the very awesome Socket.io abstraction, just mention websockets and a bunch of fallbacks in the config and get coding.

Must say having JavaScript on the server, the client and the data store is a huge advantage as well from a programming context perspective!

And.. umm.. discovered couple of hours ago that things surprisingly work great on IE9 and apart from CSS disabilities fairly well in IE8.

Of course, hard to say its production ready for all kinds of web apps, you must still choose based on your specific situation.

"Stable and ready for developers" and mixing it with links to the .Net framework 4.5 beta documentation seems off.

Sure, it can be stable. And ready is kind of subjective. But the 'Use this, now' feeling I got from the title was quickly nowhere to be found.

That said: I liked the whole walkthrough and general depth of the article.

It seems "off" because it is:

http://caniuse.com/#feat=websockets

I would love to use web sockets in my app to replace long polling but without IE/Android, it's a non-starter.

<shameless plug>

That's exactly what I thought and that's why SockJS is there: https://github.com/sockjs/sockjs-client

   a) start using SockJS

   b) wait until enough browsers supports it

   c) drop SockJS.

SockJS has a websocket-like API so no need to do major code changes when you switch.

</shameless plug>

Great idea. Exactly what somebody should have done with HTTP Long-Polling and Streaming (XHR, IFRAME, ActiveX etc.) but without a standardised API it was difficult. The WebSockets API let's us do this.

https://github.com/gimite/web-socket-js is a good fallback which uses Flash Sockets. Whether you can use them or not really depends on your target user. I'd argue that for the general public you can use them; they'll be using IE with Flash, Firefox or Chrome. With the latter two you'll have native WebSocket support and with all three it's highly likely that all with have Flash installed. Things are trickier for corporate users where it depends on the corporate IT policy. As ever, there are edge cases.

By the time you're done porting your app to websockets, IE/Android will be ready, or at least close.

try websockets, if fails, use comet.

It's not rocket science.

(Mibbit has been using websocket in production for 2.5 years or so)

I am already using comet, what's the benefit of trying websockets first?

P.S. "It's not rocket science" snark completely uncalled for.

Well, WebSockets are somewhat more efficient in terms of overhead, the latency will probably be a little better, can be handled more efficiently/easier on the server-side and it doesn't have the other drawbacks Comet has (AFAIR in some browsers, say, opera, if you use comet, you've basically used up your quota of allowed connections, so making additional XHR might be problematic.)

> try websockets, if fails, use comet

I've seen this statement, or similar, a few times. But, Comet servers use WebSockets. So, WebSockets are not an alternative to Comet. They are a transport technology that is better suited to the Comet paradigm, and building interactive web apps, than HTTP (Long-Polling, Streaming). Here's a diagram I create a while back which hopefully explains my point of view: http://i.stack.imgur.com/BOFC2.png

Spot-on about the benefits of WebSockets over HTTP-based solutions when it comes to efficiency. The HTTP connection limit was a problem a while back but I don't believe it is any more.

Huh? Android default browser (and most importantly, WebView) does not support WebSockets, and has no visible plans to support it. IE8/9 do not support WebSockets.

Some expect Chrome for Android to become the default browser (http://www.wired.com/gadgetlab/2012/02/chrome-android/) and if that happens the WebSockets will be supported. Firefox for Android also supports WebSockets.

I can't 100% confirm Chrome will become the default but Google are very pro WebSockets so it would be very strange for them not to support and encourage their use.

There are fallback options in place that mean WebSockets can be used on Android but that tends to mean Flash lite also has to be installed.

Chrome for Android supports WebSockets, and the "visible plan" is Google's plan to switch the native browser to Chrome.

Additionally, IE 10 supports WebSockets, and fallbacks exist- such as flash- to give support to earlier versions of IE.

"Production Ready", in this sense, means "finalized enough that you can feel secure about implementation", just like html5 and css 3. Should you rely on css 3 alone for old versions of IE? You need fallbacks, of course. But you can feel comfortable about implementing it (with progressive enhancement or graceful degredation) for support of less-able browsers.

One of the very real issues with WebSockets is that they don't work often over mobile networks, with invisible proxying, etc.

Unless you go with something like Socket.IO, WebSockets alone would never be a viable solution.

From my experience, working at Pusher and dealing with support for the past year, WebSockets do work over a mobile 3G connection when you use an SSL (wss://) connection. I tether (laptop -> mobile -> mobile data) quite a bit whilst travelling and my mobile data provider, O2, do all sorts of annoying things with dat (stop whitespace, inject JavaScript), but my WebSocket connections work flawlessly.

In the same way that a WebSocket library can fallback from a WebSocket connection to a HTTP-based connection it can also first try ws:// and then fallback to wss:// - it's what our library does. The potential problem here of course is that you need an SSL certificate. When using Pusher that's not a problem, because we've bought one, but when using your own hosted solution that might mean dishing out money that you'd rather not.

Try a port other than 80: I have my iPod tethered via Droid 3 on a Verizon 3G network, it blocks 80, but did not block 1800

Websockets are great, but apache and nginx are still yet to support them out of the box. You have to recompile nginx with a module and apache has to have a custom mod.

When it's a case of writing in a line in nginx.conf for a proxy bypass or commenting out an apache module then it will be ready. Using port HTTP/port 80 is one of websockets strengths.

When it comes to nginx and apache you can always go down the hosted realtime infrastructure route. That way you can use WebSockets in your client (app) but you don't need to worry about installing mods or handling the persistent connections on your server.

See: http://www.leggetter.co.uk/real-time-web-technologies-guide#...

Does anybody know how fast connecting to a WebSockets server is? How does it compare to connecting over http? I was interested in the ws:// uri scheme as I was unaware of that. Is there a future scenario where we could connect to a WebSockets server directly through the browser without first connecting over http and then with js?

I would really love a free C# implementation of a Socket.IO WebSocket, with as few external dependencies as possible.

Are their commercial versions of socket.io for C# available? When it comes to .NET people tend to go with signalR (which I think has WebSocket support but not within ISS - until Windows 8 server), SuperWebsocket or XSockets.

http://www.alchemywebsockets.net (a friend and I built this.) Handles a ridiculously large amount of connections thanks to an awesome threading model. MIT licensed. Supports the RFC version and some older versions.

By a guy from Microsoft so plenty of MS examples/links, but a good overview of WebSockets never the less. I'm interested to hear how many of use will ever actually use the `WebSocket` object? Will we (developers) always use a library offering a layer of abstraction and the real core functionality that we need.

The WebSocket API is very simple, there wouldn't be much need to abstract it.

The point in abstraction in this case is to add additional functionality.

The most obvious option, and something I thought might have become part of the WebSocket API, is auto-reconnection. To reconnect you need to create another WebSocket object and reattach all your event listeners. So, I'm convinced that the majority of people who use WebSockets will have to write their own custom code for this and will probably put it in their own little library which wraps around using WebSocket objects.

More info in the comment here: http://www.sitepoint.com/websockets-stable-and-ready-for-dev...

On a related note we put out a tech demo showing nodejs and socketio recently. http://www.webdigi.co.uk/fun/space/ It uses iPhone accelerometer to control the ship on your browser game!

I was hoping to read an article about how WebSockets are more stable and ready today than the last time I checked.