The short answer is that this was the best I know in March 2011 when I wrote these words; the preceding hyperlink to the protocol definition was only finalized eight months later, in December of that year, for instance. Several of the other facts about WebSockets are different now. It’s worth taking a few minutes to get those facts right.

HTML5 complications

WebSockets are a Web standard for full duplex–simultaneous “push” and “pull”–communications between browser and server which “… slash the latency inherent in XMLHttpRequest …”, as I mentioned this summer in “Three main choices for advanced communications in HTML5“. Whole classes of applications, including performance-intensive games and demanding interactive medical programs, were restricted to the desktop until recently. WebSockets makes these practical within a standard browser.

When 2011 began, most end users relied on browsers that did not support WebSocket. Worse, quite a few serious analysts suspected WebSocket compromised the security of the browsers that claimed to support WebSocket. While that didn’t necessarily mean that it was wrong to use WebSocket at the time, a decision to rely on WebSocket certainly wasn’t automatic.

Sites need to explain clearly and accurately when individual write-ups were written or published or posted. “Application Monitor“, the Real User Monitoring blog, does this, of course.

HTML5 is big and sprawling and full of activity. Don’t ever fall into the trap of believing that “Browser X supports HTML5″ is meaningful. You need to think always in terms such as, “which parts of HTML5 matter to me?” and “how can I gracefully retreat if this specific implementation turns out to be impaired?”

Free Real User Monitoring

This blog is sponsored by Correlsense,
the maker of SharePath RUM Express -
a free tool that provides a real-time
view into the actual experience of
your end-user, including availability,
response times and service levels.