I spend a good chunk of my life coding web apps without internet access. It’s been an interesting experience. And I learned something: offline web apps are easy to write.
When I say offline, I mean that a browser should have to hit a website for its data exactly one time (unless the data changes and they happen to be online again). Otherwise, there is no need to make any web requests.
Turns out the technology for doing this has been around for a long time. No it’s not Service Worker (yet — Safari on iOS, please hurry up) which everyone is screaming about. Older, more supported tech exists. I use:
- AppCache for static resources like HTML, JS, CSS, Fonts.
- IndexedDB for data.
Pretty much all green, so it seems safe there. The actual programming is easy too. AppCache asks for a list of files that will be cached. Even I can handle that.
IndexedDB has some very neat Key/Value+Promise wrappers which leave me with:
Is the data stored locally?
- Yes → grab it.
- No → grab it from Firebase and store it locally.
Which only leaves cache invalidation:
Are we online and has the data changed?
Yes → grab it from Firebase and store it locally.
No → nothing to see here, carry on.
Yes, my app is not GMail or something. Yes it has very static data — think an RSS reader. Yes I think I have the perfect use-case for these technologies and this approach. But it works perfectly.
Combine this with a web manifest so chrome can “add to home screen”, and I have a fully offline, cross-platform, application that feels great on Android, iOS, and elsewhere with a few hundred lines of code.
Native apps don’t have a hope for this kind of use-case. Which brings me to speculate on the likely motivations why iOS Safari doesn’t support Service Worker. But that’s not a story I’ll tell.
Thanks for reading.