Just recently I was in the process of writing a new blog post on Progressive Web Applications. In the post, I was going to document my conversion to a PWA site. This blog to be exact. And so I did what most developers who are attempting to learn something new would do. I jumped on Google and looked up "Progressive Web App". Lo and behold the first result seemed like the answer I was looking for. "Introduction to Progressive Web Apps". It's a good start.
After reading the customary few introductory paragraphs that will walk me through the process, I began to set up my environment. I downloaded the sample code that was suggested and installed the necessary software, in this just a simple Chrome plugin that would allow me to use Chome as a server. Easy enough.
At this stage, things are running smoothly. Sample code is running, server is serving and the documentation is making sense. That is, until the first caveat appeared. It seems that the sample code relies on the built in local storage functionality in JavaScript. However, it doesn't recommend using local storage. It recommends using idb. Actually, it recommended using localForage, to be more exact.
At this point I have 2 options. Either continue with the example as is, with the nagging feeling that I should be building this correctly from the ground up to begin with, or to follow the rabbit hole into a whole new realm that I didn't even know existed. So I did what any programmer would do. I jumped on the idb bandwagon.
I couldn't tell much about what idb actually was, except this.
This is a tiny library that mirrors IndexedDB, but replaces the weird IDBRequest objects with promises, plus a couple of other small changes.
So I figured I'd try my luck with localForage instead. Easy enough it seems. It's a wrapper for all offline storage methods, such as localStorage, indexedDB and webSQL. webSQL is deprecated now, so we can ignore that. Now that I know a bit more about the options for offline storage, it's time to jump back to the example. For the time being, I will continue with local storage so that I'm not slowed down too much just yet.
The next stopping point came with Service Workers. For those not familiar with them, here is a brief definition:
A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don't need a web page or user interaction. Today, they already include features like push notifications and background sync.
So before anything else, I had to branch off a bit into a few other how to's and articles on the nature of Service Workers, and how to debug them and such. This wasn't a terrible thing, as I was able to write a blog post about service workers along the way. However, during the process I was stopped once again with a detour pushing me towards Push Notifications. Just to understand the entire process more I decided to follow that tangent. Except that it was outdated.
And so instead it directed me to Web Push Notifications. So I reeled it back again once again, and went back to Service Workers. I needed to stay focused on the task at hand here. Eventually, I'll get around to using Push Notifications. But not for the sake of this example.
Things were sort of going smoothly. The lingo was somewhat new, and trying hard to sound tech-savvy for the most part.
Service worker is a programmable network proxy, allowing you to control how network requests from your page are handled.
I'm a web developer. So the term "programmable network proxy" isn't really in my day to day usage just yet. It did mention that Service Workers use Promises very heavily however, and so it insisted that I read a guide on JavaScript Promises. Which I promptly did. Or at least, I opened it in a new tab. I have a general idea about what Promises are, and have probably used them in the past in passing. This new guide however was twice as long as the original PWA one that I am barely 1/4th of the way through.
At this point, I sort of gave up on the whole idea of learning about PWA and decided that my time was much better spent on something else. Anything else. Like watching Batman: The Animated series clips on YouTube. I wish I was Batman sometimes. He doesn't have to worry about these things. He helps people, in passing, and broods about it.
A few days passed, and I had this half-way written blog post on PWA that started off with very high optimism, and ended up in a confused guide with more pasted content than I'd care to admit. So I decided to jump back into it. And to do what it takes to finish this blog post. So I decided to do what made the most sense. To ignore everything that wasn't 100% required for this conversion to work. Which means, no push notifications, no deprecated webSQL, and no 8000 word essay on the importance of JavaScript Promises. And so I went back to the PWA guide.
It seems I need to make sure that I have HTTPS enabled on my website. Which I do, luckily. If you don't however, then here is a quick guide on how I went about adding it through GoDaddy.
The next few lines made sense, and I felt like I was finally getting on the right track, and that soon enough I would have a fantastically built PWA site up and running for the world to enjoy. Then this appeared.
Fine, in the spirit of just moving forward always, I continued on. I won't use this code in production. Next up was debugging service workers through the browser, which I skipped for now, as I just want to see the thing run more than anything. I copied and pasted some more code, of which returned no errors and marched onward.
This last copy/paste seem to be the end of the journey. The application is now serving files directly from cache, and not from the network. At this point, my mind reels at the reality that this is how the internet used to work. All of this work to cache some JavaScript files and some CSS files. Something seemed odd here. Isn't that how it works now? Isn't that why "clear your cache" is the most used phrase from web developers? What's the difference between this cache and the one that the browser keeps by default??
Some tea. Some self-contemplation later. I continued to read through the material. Now that .js and .css files can finally be cached, it's time to cache the data on the website. For me that meant essentially, caching the blog posts, just in case you really need to read about programming while you have no internet. If you have no internet, just enjoy it. Take a deep breathe, look around, have a snack.
I don't know if I really learned anything about the web during this entire process. I learned other things. I learned about myself, and about not having to implement every new technology that makes the rounds on the web. Maybe next year PWA will go the route of webSQL and be deprecated too. Then we'll all be redirected to Web PWA, which is kind of the same, but not really.
The point of this article was to showcase the process that, I'm sure, many developers go through when trying to learn something new online. When trying to stay up to date with technology in a world of perhaps too much information. Perhaps this is why older folks tend to shy away from new technologies. Maybe one day I will be telling the younger folks about how in my day, the browser did the caching and we just stayed back and relaxed. Or maybe I'll just push the code live now and move on to converting the blog to an AMP website.
Walter Guevara is a software engineer, startup founder and currently teaches programming for a coding bootcamp. He is currently building things that don't yet exist.
Stay up to date
Sign up for my FREE newsletter. Get informed of the latest happenings in the programming world.