What do you get with HTML5 web sockets that you can't have with AJAX?

Question

Ian Hickson says:

I expect the iframe sandboxing feature will be a big boon to developers if it takes off. My own personal favorite feature is probably the Web Sockets API, which allows two-way communication with a server so that you can implement games, chatting, remote controls, and so forth.

What can you get with web sockets that you can't get with AJAX? Is it just convenience, or is it somehow more efficient? Is it that the server can send data to the client, without having to wait for a message so it can respond?

Answer 1

Yes, it's all about the server being able to push data to the client. Currently, simulating bi-directional communication without Flash/Silverlight/Java/ActiveX takes the form of one of two workarounds:

• Traditional polling: Clients make small requests to the server frequently, checking for updates. Even if no update has occurred, the client doesn't know that and must continuously poll for updates. Though each request may be lightweight, constant polling by many clients can add up quickly.
• Long polling: Clients make periodic requests for updates, like regular polling, but if there are no updates yet available then the server does not respond immediately and holds the connection open. When an update is finally available, the server pushes that down to the client, which acts on it and then repeats that process. Long polling offers push-like update resolution, but is basically a self-inflicted DDoS attack and can be very resource intensive for many types of web servers.

With WebSockets, you get all of the responsiveness advantages of long polling, with dramatically less server-side overhead.