The same can be said of many of the other remarks in the article. You could even say it is elegant that SPDY only changes things under the hood, and keeps the good parts of HTTP.

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 :-)

Sure. Same here. I was writing js chat and realtime games back in '99.

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'

Another thought would be simply that if SPDY makes it more attractive/easier/secure/efficient for developers to implement push, then users will benefit simply from it being included in more apps.

Except that it's faster, more secure and less prone to bugs caused by poor implementations of comet and other long polling techniques.

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.

End users might not notice speed improvements, but they do respond to them, according to the data.

SPDY vs comet may be noticable if you're doing a real time game or something. But SPDY vs websocket should be the same.

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"

SPDY also speeds up ordinary page loading.

WebSockets do not work "just fine." Please don't use them.

You're going to have to give us more than that to go on. Like, you know, an actual downside to using WebSockets?

An anecdote: About a month ago, just to experiment with websockets I built a tiny app using Tornad. I spent a long time trying to figure out why it didn't work before I realized that the latest versions of Tornado and Chromium spoke different versions of the web socket protocol. When Tornado 2.1 came out, the app started working.

The WebSockets standard is not finalized. Everybody deploying today is deploying a draft which is subject to change.

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.

I, and thousands of my users, use them fine every day thanks.