I was going to blog about HTML5 WebSocket last week, but got side tracked. In the meantime, Greg Wilkins wrote an excellent piece covering some of what I wanted to say: http://blogs.webtide.com/gregw/entry/websocket_chat
The idea of WebSocket is sound – it should get past some of the limitations of the various Comet techniques used today on various real time websites. It gives you full duplex communication between a browser and a server – Comet fakes this somewhat, but in most cases it is sufficient.
Some people seem to think that WebSocket is going to mean no more Comet servers and no more frameworks for real time data. But as Greg points out, WebSocket just doesn’t give you enough.
I see three main issues with WebSocket, or rather its uptake by web developers.
1. Browser support
We still have to deal with IE6 at the moment and WebSocket is not supported yet in the current browsers (apart from Chrome). So when can a web developer realistically rely on WebSocket being available for the majority of his users? This is likely to remain an issue for a long time.
2. Proxy support
WebSocket through proxies are a fairly unknown quantity – WebSocket is designed to fail cleanly so falling back to another mechanism is possible. However we don’t really know how many proxies will work with WebSocket. This includes server side proxies, which are often overlooked and are usually out of the control of the server side developer.
3. Features
What I am referring to here are the low level features that Greg talks about. His blog demonstrates that you cannot just take the simple WebSocket API and write a real time application (other than a demo) without taking into account the kind of edge cases he describes. Without this a web application could appear unstable for many users.
Taking all this into account, what is WebSocket good for? Who should use it?
Conclusion
Application developers use frameworks that hide issues and allow them to concentrate on their application, not the infrastructure. Frameworks can handle the error cases and implement various fallback methods for when WebSocket doesn’t work or an old browser is being used – there are free and commercial frameworks offering this.
So in this sense while Websocket will not improve web applications directly, it is something that framework developers can use to improve their frameworks – consequently improving those web applications that use the frameworks.
This isn’t so much of a “why we don’t need websockets” so much as a “why i’d rather not care about websockets” post. Most sites have dropped IE6 support, proxies have a nasty habit of killing off long-polling comet requests, and the complexity is not a factor: all other solutions for “push”-style requests are complicated, but are in a wrapper for simplicity. I can only imagine that WebSockets will have numerous libraries to wrap it when it’s available.
Hi Matt,
It’s good to see some big players dropping support for IE6, hopefully it will have a knock on effect, but at the moment a lot of corporate users still have IE6, besides that IE7 and IE8 don’t have WebSocket either – so I don’t really see the finish line for widespread WebSocket support unfortunately.
I think most people will be using WebSockets in one of two ways.. either using an existing Comet solution that adds WebSocket support, but still covers all the other connection techniques… or for new Web apps that are on the cutting edge and more of a demo/showcase and don’t have to worry about users that much.
It seems the proxy support should even get easier with websockets?
“A Web Socket detects the presence of a proxy server and automatically sets up a tunnel to pass through the proxy. The tunnel is established by issuing an HTTP CONNECT statement to the proxy server, which requests for the proxy server to open a TCP/IP connection to a specific host and port. Once the tunnel is set up, communication can flow unimpeded through the proxy.”
http://www.websockets.org/about.html
That site is from a WebSocket vendor, who also blogged recently about proxy issues. I covered this on a more recent blog http://blog.caplin.com/2010/04/13/html5-websocket-failure-rates/ where Google did some tests and found a lot of users cannot connect through proxies.
The HTTP CONNECT method only helps when the browser knows about a proxy, which isn’t always the case.
In a similar vein: http://blog.caplin.com/2009/12/17/the-rumours-of-comets-death-have-been-greatly-exaggerated/
Well there are flash fallback solutions, so to me the question is just what to do with mobile clients that atm do not support websockets (i hear early beta releases of the iPhone 4.0 iOS supported them) nor flash (this might change soon, though obviously not for the iPhone).
about the supporting browsers…
Safari, safari for iphone4 & firefox 4 are now supporting the websockets…
and as of web-socket implementation by framework with decent fail back to comet techniques… check out https://atmosphere.dev.java.net/
It’s a shame they support different, non compatible, versions of the WebSocket spec though!