Why we don't need HTML5 WebSocket

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.