Offline First – A better HTML5 User Experience

For most apps (which derive their usefulness from dynamic content), what's the point? Is an app that loads but does nothing really worth all the extra development time?

That being said, if you're already making a mobile app or API to go with your site, it does make sense to decouple the frontend (HTML/Cocoa/whatever) from the backend so you only write the backend once. Best way to have an up-to-date, useful API is to use it yourself.

So, in other words, the web is rediscovering client/server programming. Welcome to 1990, everyone!

More seriously, though, I think a lot of the reason for the historical tendency towards server side rendering has been:

* Clients were slow: remember, until V8 raised the standard for speed, Javascript VMs were slow. So doing a lot of rendering or data processing in Javascript was a bad idea, since it negatively affected the user's experience with their entire computer, not just your site.

* DOM Manipulation is hard and inconsistent between browsers: Yes, JQuery and friends hide the native DOM API. But we have to remember that it wasn't always the case. Rich client-side libraries are all quite young, comparitively.

* Offline capabilites were non-existent: Even today, the HTML5 specification, as implemented, only grants you a fraction of the data storage and retrieval capabilities available to even the most sandboxed application. And previously, these capabilities simply weren't there - if your app needed to store data, it had to store data server side and tag the client with a cookie or some other for identification to keep track of which data belonged to whom.

Yes, there is progress being made on all three fronts, but you can't expect developers to throw away years of best practices in a day, then immediately turn around and write HTML5 webapps. I think the evolution towards a more balanced computing model (where more of the computational load is being handled by the client) is ongoing, and will accelerate as browsers become more capable.

People are consuming more content on mobile year on year, and using offline storage and capabilities have been around for the past year or two; how this is only just bubbling at the surface at conferences is beyond me.

Take THE white elephant example; Facebook mobile. The shift is evident, my girlfriend doesn't use a traditional desktop/laptop anymore she consumes all her Facebook glutton through her mobile. If it takes more than 5 seconds to load she gives up.

There is a grey gap in knowledge of accepted and logical practice with what stays online or offline but for example the whole of Facebook's UI could be cached on a mobile and just reload the updated news/feeds.

It's still quite tricky to to detect a reliable 'offline' state with HTML5. Using navigator.onLine tells you that you 'might have' internet access but even then you may actually be offline. Bu I agree that the most important issue is how to communicate the degradation to the end user.

Yeah, I saw a lib the other day that tried to offer this but was pretty hit and miss, and checking into the methods available didn't fill me with confidence. Right now I'm only considering the client offline if an attempt to hit the server fails. If they're trying to save something, queue it up to do later, if they're trying to retrieve something, check if theres a copy locally, if not let them know what's going on.

The problem with this method is ideally you'd like the client to know it's reconnected as soon as possible, and start working through the queue. I figured the most foolproof way was just periodically trying to talk to the server when you think you're offline. It'd probably be better if you had a solid method of receiving actual network related events like disconnecting and reconnecting, but the lazy 'just keep checking' method is workable.

The bonus of it is it works the same if it's a problem on the servers end.