4 ms·

It seems "off" because it is: http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets I would love to use web sockets in my app to replace lon

by rada 15y ago

It seems "off" because it is: http://caniuse.com/#feat=websockets http://caniuse.com/#feat=websockets I would love to use web sockets in my app to replace long polling but without IE/Android, it's a non-starter.

leggetter 15y ago
https://github.com/gimite/web-socket-js https://github.com/gimite/web-socket-js is a good fallback which uses Flash Sockets. Whether you can use them or not really depends on your target user. I'd argue that for the general public you can use them; they'll be using IE with Flash, Firefox or Chrome. With the latter two you'll have native WebSocket support and with all three it's highly likely that all with have Flash installed. Things are trickier for corporate users where it depends on the corporate IT policy. As ever, there are edge cases.
Cacti 15y ago
By the time you're done porting your app to websockets, IE/Android will be ready, or at least close.
mibbitier 15y ago
try websockets, if fails, use comet. It's not rocket science. (Mibbit has been using websocket in production for 2.5 years or so)
- rada 15y ago
  I am already using comet, what's the benefit of trying websockets first? P.S. "It's not rocket science" snark completely uncalled for.
  - Amadiro 15y ago
    Well, WebSockets are somewhat more efficient in terms of overhead, the latency will probably be a little better, can be handled more efficiently/easier on the server-side and it doesn't have the other drawbacks Comet has (AFAIR in some browsers, say, opera, if you use comet, you've basically used up your quota of allowed connections, so making additional XHR might be problematic.)
    - leggetter 15y ago
      > try websockets, if fails, use comet I've seen this statement, or similar, a few times. But, Comet servers use WebSockets. So, WebSockets are not an alternative to Comet. They are a transport technology that is better suited to the Comet paradigm, and building interactive web apps, than HTTP (Long-Polling, Streaming). Here's a diagram I create a while back which hopefully explains my point of view: http://i.stack.imgur.com/BOFC2.png http://i.stack.imgur.com/BOFC2.png Spot-on about the benefits of WebSockets over HTTP-based solutions when it comes to efficiency. The HTTP connection limit was a problem a while back but I don't believe it is any more.
majke 15y ago
<shameless plug> That's exactly what I thought and that's why SockJS is there: https://github.com/sockjs/sockjs-client https://github.com/sockjs/sockjs-client a) start using SockJS b) wait until enough browsers supports it c) drop SockJS. SockJS has a websocket-like API so no need to do major code changes when you switch. </shameless plug>
- leggetter 15y ago
  Great idea. Exactly what somebody should have done with HTTP Long-Polling and Streaming (XHR, IFRAME, ActiveX etc.) but without a standardised API it was difficult. The WebSockets API let's us do this.
deleted 15y ago
[deleted]

by rada 15y ago

leggetter 15y ago

https://github.com/gimite/web-socket-js https://github.com/gimite/web-socket-js is a good fallback which uses Flash Sockets. Whether you can use them or not really depends on your target user. I'd argue that for the general public you can use them; they'll be using IE with Flash, Firefox or Chrome. With the latter two you'll have native WebSocket support and with all three it's highly likely that all with have Flash installed. Things are trickier for corporate users where it depends on the corporate IT policy. As ever, there are edge cases.

Cacti 15y ago

By the time you're done porting your app to websockets, IE/Android will be ready, or at least close.

mibbitier 15y ago

try websockets, if fails, use comet. It's not rocket science. (Mibbit has been using websocket in production for 2.5 years or so)

rada 15y ago
I am already using comet, what's the benefit of trying websockets first? P.S. "It's not rocket science" snark completely uncalled for.
- Amadiro 15y ago
  Well, WebSockets are somewhat more efficient in terms of overhead, the latency will probably be a little better, can be handled more efficiently/easier on the server-side and it doesn't have the other drawbacks Comet has (AFAIR in some browsers, say, opera, if you use comet, you've basically used up your quota of allowed connections, so making additional XHR might be problematic.)
  - leggetter 15y ago
    > try websockets, if fails, use comet I've seen this statement, or similar, a few times. But, Comet servers use WebSockets. So, WebSockets are not an alternative to Comet. They are a transport technology that is better suited to the Comet paradigm, and building interactive web apps, than HTTP (Long-Polling, Streaming). Here's a diagram I create a while back which hopefully explains my point of view: http://i.stack.imgur.com/BOFC2.png http://i.stack.imgur.com/BOFC2.png Spot-on about the benefits of WebSockets over HTTP-based solutions when it comes to efficiency. The HTTP connection limit was a problem a while back but I don't believe it is any more.

majke 15y ago

<shameless plug> That's exactly what I thought and that's why SockJS is there: https://github.com/sockjs/sockjs-client https://github.com/sockjs/sockjs-client a) start using SockJS b) wait until enough browsers supports it c) drop SockJS. SockJS has a websocket-like API so no need to do major code changes when you switch. </shameless plug>

leggetter 15y ago
Great idea. Exactly what somebody should have done with HTTP Long-Polling and Streaming (XHR, IFRAME, ActiveX etc.) but without a standardised API it was difficult. The WebSockets API let's us do this.

deleted 15y ago

[deleted]