For non-games usually Server-Sent Events (http://dev.w3.org/html5/eventsource/) may be simpler to use:

• it's pure HTTP, message format is dead simple ("data: payload\n\n")

• browser handles network failures and reconnections automatically.

• browsers can share same stream URL between windows

His use-cases with to-do app and analytics were good fits for SSE.

Once Firefox supports SSE I agree that it would be easier to implement in many use cases. Although it doesn't have the same sort of fallback mechanisms available to it that WebSockets have (ActionScript sockets).

Here is some additional information about it that I found at stackoverflow: http://stackoverflow.com/questions/5195452/websockets-vs-ser...

You can fall back to XHR with long polling — the stream is trivial to parse.

I'll check that out, thanks!

slides: http://www.slideshare.net/CameronWestland/websockets-8031217

Is anyone else kind of baffled by the comment about the political risks of web sockets? Why do people waste time with answers like that?

Hi Neoveller,

I gave the talk and I agree the political risks comment was misplaced. I didn't think it was worth it to shut the person down though as it's my personal philosophy never to embarrass anyone if possible.

I hope you found the others parts of the talk more useful.

I can't watch the slides, but I wonder if they spend any time discussing how WebSockets don't offer any client security beyond raw TCP sockets.

Why would WebSockets offer any client security beyond raw TCP sockets?

It was one of the original promises of WS and the reason that browsers offer it to client-side JS.

There are some people building on top of WebSockets with an eye towards security. Check out http://pusher.com/ for example, they designed system to account for 100% untrusted client.

I agree, security in Web Socket must be robust/comprehensive in both ends. This post says so too: http://blog.kotowicz.net/2011/03/html5-websockets-security-n.... Thanks!