If the request does fail, you won’t know whether it made it to the server or not.

If the connection is slow, or flaky, it may well stay that way.

An application designed along these traditional lines, built on the assumption that an Internet connection is not just available, but reliable and fast, will be incredibly frustrating to use over a poor-quality connection.

Getting into the offline mindset requires only one key realisation: when you leave the world of timely, reliable communication, the local database, not the server’s, must be the gateway for all persistent changes in application state.

When your application is designed this way, its “offline” usability skyrockets.

Do HTML5 apps have to be online all the time?

One would think that almost five years after the definition of HTML5 offline capabilities this question would be answered. As someone spending a lot of time on HTML5 panels and Q&A sessions at conferences I can tell you though that it gets asked every single time.

The problem is that these are details that don’t interest the business person considering using HTML5. All they hear is experts complaining and bickering and saying that offline HTML5 doesn’t work. Which isn’t true. It doesn’t work perfectly, but nothing on the web ever does. Many, many things in Android and iOS are broken, and many apps don’t work offline either. These shortcomings are not advertised though which makes native apps appear as a much more reliable alternative. We should stop showing our behind the scenes footage as a highlight reel.

Network connectivity: optional

Making Stuff work offline used to be very easy. It has only become an issue with the advent of the internet. [...] The only stream you needed from outside the building was electricity.

These days most devices will ship with a "cache for electricity" which can be used if the stream is not available. And we call it battery.

In the same way it makes sense to build interfaces mobile-first, it’s time to think about designing and building our applications offline-first

Wouldn't it be great if things Wikipedia, Google Maps and Youtube would once again be resilient to fluctuations in connectivity [showing CDs of Encarta, 3D World, ...]

Online first: Users with connectivity get fresh data all the time, users without connectivity are reused. This is graceful degradation. And as we found with graceful degradation, it's the wrong way around. [...] you cannot make assumptions on connectivity, but you do, per request, when you rely on it.

Offline first: The next generation of progressive enhancement treats the network as a potential enhancement that might not be available.

Sure, connectivity is getting better. But it's very rarely going to be faster than getting stuff straight off the device. This whole thing's as much about improving performance for user with connectivity, as it is for giving something to those without.

Developing for the internet has huge advantages. If a thing has a screen, it's more and more likely to have a browser on it. When someone goes down the native path and develops versions of the same thing for different languages, as a platform, we must ask why and fix that bug because it is a bug.