Hacker News Reader

Comment by axod | Hacker News Reader

Relying on feature detection alone for WebSocket is a big mistake though. Websocket can fail for a number of reasons - proxies, stupid ISPs that interfere with HTTP traffic etc.

In Mibbit, the code is something like this:

  if(WebSocket in window) {
    tryWebsocket();
    window.setTimeout(function() {
      if (nothingHappened()) useComet()
    }, 5*1000);
  } else {
    useComet();
  }

Where comet in this case is keep alive long polling XHR.

View on HN

That's an interesting way of managing timeouts. Is the 5*1000 intended to just be a more readable way of specifying seconds?

I assume so. I do the same thing.

Closure compiles it down to 5000 or 5E3 or whatever is smallest in my build process, so all the browser sees is '5e3'.

I find 5*1000 most readable in my source code though.

Libraries like Socket.IO will detect if the connection can be made or not... so this point is moot.

Feature detection first, connection detection second, then start degrading the transport until all options are exhausted.

Sure. I was just explaining for those who prefer to write things like this themselves.

How can you check if nothing happened?

By changing some global variable in the callback and checking if it has changed in 'somethinghappened' (which only gets called after 5 seconds, giving the callback time enough to get called).

Reply on news.ycombinator.com