Server-Sent Events have quicker handshake, send events down just as fast as WebSockets, and automatically reconnect (so works like WebSocket on stable connection, long polling on unstable).
SSE also works across all proxies, which even if you are on a stable connection you might have a transparent proxy that borks websockets, so that's at least one reason to prefer SSE over websockets on a stable connection. A work around then is to use wss: instead.
I like this. The other day we were thinking about how the suggested practice these days is to start with long-polling first, then attempt to upgrade to WebSockets (as opposed to the other way around). But, in some cases it's not the browser but the network that prevents WebSockets from working. This means if you wander to another network that doesn't support WebSockets, you actually still want a way to downgrade back to long-polling.
Maybe such best practices could also include some kind of poll/ping interval that adjusts based on the apparent stability of the link. Stable or wired connections could have very large intervals.
That will introduce yet another delay/flapping point for people on unreliable connections:
You start with a longpoll and get some data, then negotiate websockets (hey, my network and browsers are websockets capable!). Then the connection drops. And then you go through another round of everything again when you get back online (http + longpoll + websockets, instead of just http + longpoll).
Odds are, your website doesn't need websockets anyway, and 99% of your users are just fine with waiting a couple of seconds more to get their notification (and in the process, people with unreliable connections can still use your site).
Of course, if you're doing online stock trading notifications or something like that, you might actually need these two seconds. But then I'll strongly question your choice of using a browser for that :)
> Odds are, your website doesn't need websockets anyway
Odds are your website doesn't need CSS, but it certainly can benefit from it! I don't disagree that almost all websites could get by just fine without websockets, but that seems like an incredibly anti-innovative approach to web development to me. Instead we should focus on making the experience better, as opposed to just avoiding innovation altogether.
> 99% of your users are just fine with waiting a couple of seconds
Pretty much every study done in the last few years has suggested that is completely false, that as wait times rise above a second, the number of visitors who simply close out rises exponentially.
I question the value of websockets in most cases, because in most applications I can think of (except maybe games and high-frequency trading), they don't bring me any value and actually prevent me from interacting with the website in a meaningful way (yes my connection is crappy, but that is the case for a big chunk of the online population).
Sure, I can't think of all applications that would benefit from websockets, but so far, none of the ones I've seen do. I'm certain you can find at least a few exceptions, but my point is that it is only this: exceptions.
Anything that has a volume of changing data that needs to be close to real time would benefit. Anything that has that requirement and also wants to be available on the web would most certainly benefit. High-frequency trading and games/betting/TV-related-data (e.g. NASCAR), etc are definitely cases. How about just anything that is currently done via polling and wants to reduce network overhead? There are a lot of those types of applications. (full disclosure - I work for Kaazing, the leading enterprise WebSocket company, though I'm most definitely not speaking for them in any capacity).
I'm sure there's some small difference between waiting a second for the page to load and receiving a notification a second later. Presumably the notification hadn't existed at page load, or what are you doing delivering it by web socket in the first place?
Maybe we just change the user to long poll after a couple disconnects?