3 ms·

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 WebSocke

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.

swah 12y ago
Its also interesting how Gmail doesn't try to hide that its connection problems.
tribaal 12y ago
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 :) EDIT: fixed stray "*"
- nmjohn 12y ago
  > 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.
  - tribaal 12y ago
    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.
    - davecombs 12y ago
      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).
  - qu4z-2 12y ago
    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?

swah 12y ago

Its also interesting how Gmail doesn't try to hide that its connection problems.

tribaal 12y ago

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 :) EDIT: fixed stray "*"

nmjohn 12y ago
> 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.
- tribaal 12y ago
  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.
  - davecombs 12y ago
    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).
- qu4z-2 12y ago
  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?