I think the bit outstanding question is about scale.
The comet connection requires 2 keep-alive HTTP connections to make a full-duplex connection. So obviously a single socket connection doubles the number of users a single box can handle - does it actually scale that way?? Don't know.
You've also got to wonder about the extra overhead of running deflate on everything that you send with the XHR version of the code, and why there couldn't be some sort of compression applied to the packets sent through WebSocket if it is a really big deal.
Also, obviously, the smaller your send/receive, the better the improvement that your websocket code would see over XHR.
I can imagine an application of websockets where you open multiple sockets and send a number of constantly updating data-streams from the server.
A lot of articles seem to imply that websockets is simply XHR 2.0, and I'm sure it will be used as such for a while.
But it seems to me that there are certain things that you can do with this that simply cannot be done efficiently with other technology.
(Imagine being able to smoothly track a mouse cursor or watch another person edit a document in real time, how would you do that with XHR?).
>> "or watch another person edit a document in real time, how would you do that with XHR?"
Works fine on Etherpad.
Having said that, I agree, the lag with WebSocket is likely to be a less. Hopefully WebSocket will get the ability to do deflate/gzip soon as well. That would make it a very clear winner.
Really? You're still sending packets, so instead of sending roughly 1k of data, you're going to send a packet with roughly 1 byte of information on each keystroke?
What I'd really like to see is the breakdown of the number of packets sent as opposed to the number of bytes. I doubt the difference would be as significant.
