Hacker News new | comments | show | ask | jobs | submit login

Today I learnt something that I didn't know exist, so i'm actually really glad that you linked this project, it made me look for details on the spec/standard.

First of all, I looked through your code and couldn't understand how this was implemented. After I found it and researched, it's clear that it's essentially useless[1].

I'm not bashing on your project, I like it, but aside from being a cool gimmick, I can't think of any real world usages?

...Unless your application is LAN-based , offline-heavy, or your have pixies that run around your office pulling out your network cable regularly * chuckles *.

I'll explain, but please correct me if I am way off the mark.

The project connects to the network events

     this.events = {       
        network: ['online', 'offline']
These events fire from observing the attribute

This attribute returns true, when the system is connected to a network, but returns false when it isn't.

The importance of this is that the attribute is inherently unreliable. A computer can be connected to a network without having Internet access. [2]

This is a barebones minimal example that doesn't have the features you added:

      <title>Online status</title>
       function updateIndicator() {
         document.getElementById('indicator').textContent =
                       navigator.onLine ? 'online' : 'offline';
     <body onload="updateIndicator()" onoffline="updateIndicator()">
      <p>The network is: <span id="indicator">(state unknown)</span>
You can see the fiddle here: http://jsfiddle.net/3rRWK/

If you disconnect yourself from your network you will see the fiddle update to "Offline", however, if you pull your phone-line from your router, it will still stay at "Online".

    [1] : It's inherently unreliable. 
          A computer can be connected to a network without internet access.
    [2] : http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html

> A computer can be connected to a network without having Internet access.

In fact, as the Internet is essentially a network of networks some of which may be connected and disconnected at arbitrary points in time, it is a bit difficult to strictly define what it means to have Internet access.

In practice it would probably mean something like "can access a large majority of servers that consider themselves to be Internet servers", which is however impractical to test for. A "good enough" substitute is often enough to test connectivity to a few representative services which are unlikely to be unreachable all at the same time if you consider yourself to have "Internet access" (Google, Amazon, ...).

In this case it would however be best to test connectivity between the user and the specific server that the user is supposed to access.

Usually it's pretty irrelevant which servers are accessible except the ones that host your app/back-end. So that's what you should check when implementing such a feature.

An option would be to connect via websocket to a server and react on the disconnect event (doing some simple ping-pong to keep the connection alive). That would require an always-on websocket server though, which is a different story. Still could be good enough for a gimmick like this.

The always-on server could be provided as a (paying?) service, and there could be a polling fallback. That would be a lot more useful.

"it's clear that it's essentially useless"

Completely wrong. If 98% of the time (or even 50-97%)(i.e., reality) being connected to a network means also being connected to the internet, then it is useful. And it is also does not throw false negatives.

I took a quick look at the spec:

> The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail), and must return true otherwise.

So, strictly speaking, if you have a network connection and no internet connectivity (and the browser is not aware of the latter), this should return true - because clicking a link will result in the browser contacting the network.

What would be really interesting to see is how this works with various browsers in Windows, because Windows does test connections for internet connectivity.

> ...Unless your application is LAN-based , offline-heavy, or your have pixies that run around your office pulling our your network cable regularly * chuckles *.

add in wireless device on a network that doesn't cover all areas of the building where the application is used.

We've had to handle this situation.

The issue with the OP's implementation and yours is that not all browsers implement navigator.onLine the same way. For example, if you run the jSFiddle on Firefox, you would see that the status does not change even if you pull out the cable or turn off WiFi. This is because of how Firefox chooses to interpret the spec. However, if you enable offline mode in Firefox (File -> Work Offline), you can see that the status changes.

This issue is described in greater detail here - http://schalk-neethling.com/2011/05/navigator-online-and-the...

I smell a feature addition that polls for some virtually-always-online internet resource, such as google.com, to routinely distinguish between the various values of 'online'.

Windows (and other OSes) already do this: http://blog.superuser.com/2011/05/16/windows-7-network-aware...

Basically, systems looks up a particular domain name and then requests a text file from that server. It then also checks if another domain name resolves to a hard-coded IP. If both checks pass, you're on the internet.

It may not be 100% reliable, but coupled with other techniques (catching error 404s etc) this provides a nice way to inform the user that their connection to our application may be gone.

For single page apps that use browser storage and sync to the remote periodically it is great to be able to inform the user that "Hey you're offline. You can keep using it, but your changes won't be available for others to see until you re-connect".

Wouldn't it be easier and more reliable to just catch the failed sync?

Aah, that explains why it didn't work for me (VM network cards were still active). Seems to me like setTimeout-based polling to your server or something like http://www.msftncsi.com/ncsi.txt is still the best option.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact