I'm more interested in browser developments that mean you can do stuff you couldn't before - access to geolocation/multitouch/sound/webcam etc.
I'm more interested in browser developments that mean you can do stuff you couldn't before - access to geolocation/multitouch/sound/webcam etc.
SPDY is technically very cool. It's the update of HTTP that was way overdue. I didn't even mention end-users. Not only the user-facing parts of technology are important.
I've been playing around with asynchronous notifications to the browser for more than 10 years, when I wrote a simple html/js-based continuously loading chat. I've seen it all, from polling, comet, flash-based TCP, longpoll, to finally websockets. So for me it's great to finally see server push taken seriously as part of the spec and not sewn on as a third leg :-)
Don't get me wrong, SPDY is cool and good to see. But users won't notice any real difference. It's like when someone re-does a flash game in HTML5 and we (as geeks) go 'wow awesome', and non-geeks go 'uh? so what'
The non-geeks do notice. They notice when things don't work on their iPads. They'll notice as security and TLS become a larger and larger focus, and mobile users should appreciate the lower header overhead.
I'm just saying, it's not "wow you can now do X you couldn't before". It's "Oh they made X a bit faster"
There is no single version of WebSockets which all browsers support. Firefox is not currently shipping WebSockets, but MozWebSocket, which is subtly different and also named differently to discourage usage. They don't want people doing WebSockets. (Aside: Try finding a Moz employee willing to talk about WebSockets. None are listed on the work page in their wiki.) Chrome ships the supposedly-insecure Hixie-76. Which is also HyBi-00. Which leads to...
WebSocket's versioning is somewhere between misleading and nonexistent. Many deployed versions predate the versioning header, so they have to be detected ad-hoc. The version in the protocol isn't always bumped with every new draft that comes out.
The protocol tries so very hard to be HTTP, but can't always cross proxies. This is really only important because (a) long-polling and Comet can easily cross proxies and (b) WebSockets aren't HTTP. It's less code to write a non-HTTP WebSockets server than to bolt one onto an existing HTTP server.
WebSockets security is non-existent. There is no WebSockets protection against proxy attacks, and there is no same-origin policy, so there is nothing stopping an attacker from opening a WebSocket to an unfriendly domain. No security advantage over boring plain sockets. (To their credit, WebSockets do specify SSL/TLS interaction.)
There are more issues, but that's what comes to me from memory after spending the better part of a year caring about these damn things.