Thoughts on Web Development

I recently completed an all-offline mobile web app for a client. I was quite proud of the finished product, but had a few realizations about the state of offline web applications that I thought were worth sharing.

Below are some of the insights I took away from the experience.

Insight #1: Offline capabilities are different across devices and browsers.

If you want things to work well across different devices and browsers, don’t make your app dependent on offline capability; use it sparingly. On the other hand, if you really need deep functionality (i.e., you want your app to work completely offline), be prepared to be very specific about the devices you’re targeting, and very limited in functionality.

In this client’s case, the app we built was a prototype. They wanted full offline functionality, but we only had to cater toward iOS 8 (specifically on a full-sized iPad) and Internet Explorer 10/11 on desktop.

Insight #2: Offline database technology is fragmented.

There are too many database technologies. Local storage has size limits. If you want to store data beyond a few MB, you’ll have to rely on the browser’s offline database technology, which is different from browser to browser. IndexedDB isn’t well supported in iOS; WebSQL isn’t supported in IE or Firefox, and is being phased out entirely. Solutions like PouchDB are great attempts at working around this, but may not work in some cases and still have cross-browser problems.

Insight #3: Proprietary quirks exist.

In this last project we used several of apple’s Safari features for running a web app like a native app. We ran into surprises.

Some of Safari’s custom meta tags not behaving as specified

“Full screen mode” apps having their own storage and cache. This is a great idea, but wasn’t well documented by apple.

This at the previous insight are reminiscent of what I’ve seen in front-end development throughout my whole career: as long as browsers are made by different manufacturers, front-end development will remain challenging.

Insight #4: True offline debugging can be a real challenge.

Once you put your iOS device into Airplane Mode, you can’t debug from your laptop anymore. And since “full screen mode” apps (i.e., mobile web apps) behave a little differently than apps you view directly with the browser (see the last bullet), this makes developers unable to test offline apps completely reliably, and therefore our finished product may be unpredictable.

Application manifests (the document that tells the app which files to save offline) also have many complexities that make it challenging both to develop and debug. Application Cache is a D-bag talks about some of them without pulling any punches.

Insight #5: Offline web apps are complex.

An offline web app has as many moving pieces as a normal web app, with a few more related to connectivity and the state of the data that is on the user’s device. You have to plan out how the app will look and behave under a few situations that you don’t have to consider with a more traditional app.

For example, should you store just the html offline, or images and javascript as well? If the app runs offline, and makes an AJAX request to something that isn’t cached, is the JS set to fail gracefully? If the content manifest downloads in the background while we’re online, should we swap it out, even though the page is already rendered? If so, do we need to update the DOM based on the manifest’s contents?

Summary

All in all, making your app function offline in some portion can be a very powerful thing if your business case warrants it. Just be sure you plan things accordingly and are talking to someone with knowledge of the limitations of offline applications as you are designing your app.