Offline? No dice!

A few days ago I was on vacation in a place that had terrible mobile connectivity and whilst it provided WiFi, nothing worked. I even brought my own cables and travel router, but to no avail. This was not only a good opportunity for some “digital detox”, but it also showed me once again that the web isn’t as resilient as we want it to be.

Here’s what happened: one evening we went to the hotel lounge to play some games. They had a library with some, but the one thing that was missing was a dice.

Not to worry, I thought, and went to look on my mobile phone to get a quick dice solution on the web. There are a lot out there, but here’s the kicker: I couldn’t find any that loaded quickly and subsequently worked offline. None. At. All. Any web search for “offline dice” resulted in tons of apps advertised to me. Other online solutions are riddled with ads and have a first load of several megabytes. Interestingly enough, searching on Desktop has better solutions – the place were you are less likely to need a simple solution that works offline. There is also a huge difference between search engines.

Even those that are excellent in their randomness like the one on random.org do a reload of the whole page on every “throw” of the dice. Others implemented the sides of the dice as images and didn’t preload them.

“Simulating a dice throw” is an example of every programming language tutorial I’ve ever seen. I remember learning BASIC and Pascal and these were parts of it. I’ve also seen this come up in job interviews back in the day. Offline functionality is also not that hard to do. A simple single-purpose web product like a dice simulator should be not hard to release. It seems the lure of selling it on an app store or making money with it by surrounding it with ads is a bigger incentive though.

The solution was to go back to the hotel room, get my laptop and write a JavaScript solution in a local file whilst my partner went out for a cigarette break. I am not proud of the code, but I also had a few drinks before – and it did the job.

It made me think though. Despite dozens of tutorials, books, presentations and videos, considering offline and bad connectivity is still not ingrained into our thinking as developers.

When HTML5 became a thing and the web went mobile first, offline availability was a main need to match native apps. Earlier approaches like AppCache had a lot of issues which is why we came up with ServiceWorker. ServiceWorker went through a lot of iterations, and as it was designed to cater to a myriad of use cases, it became complex. Many people use abstraction libraries like Workbox instead.

And, I am to blame, too. Last year I released a dice emulator for fun and the thing I didn’t do is to make it work offline. Although it was a single HTML document. Now I added that functionality. So if you go to it now, it loads quickly even on a horrible connection and will subsequently work offline. You can also install it as an app.

I will write up in detail how to do that, but the source code should give most of the clues. The biggest obstacle was to make it work with GitHub pages rather than a bespoke domain (which I may add later).

To me, this taught me to be more concerned about edge cases of our users. I want the web to be there for people when they need it. And if the functionality they need is a random number between 1 and 6 they shouldn’t have to download an app for that. So let’s embrace a flaky web in everything we do.