Every browser imposes their own user interface cluttering up the screen, a fact of life for all web apps. This clutter motivated me to give my Compass web app a full screen option to get rid of those browser interface elements. It's pretty good, but it requires the user to press that "Go Fullscreen" button. What if a web app can launch in full screen state, just like native apps? That's one of many "native app like" upsides to a PWA (Progress Web App) so I started reading "Learn PWA!" published by the Google Chrome developer relations team at web.dev. The technology has promise but today's landscape has a lot of differences across browser support that make a developer's life difficult.

A core component of PWA is the "service worker", a chunk of JavaScript associated with a web app but runs behind the scenes separately from the rest of web app code. It has the ability to intercept all network requests of a web app, acting like a web server to the rest of the web app but running without a server. This makes it possible for a PWA to run without a network connection, just like native apps could. Making server-like behavior possible are a series of technologies, most of which are usable independent of PWAs.

The service most surprising to me was IndexedDB API, a structured storage database available to web apps across most modern browsers. It is a NoSQL database along the lines of MongoDB, except running entirely within the browser. Wow! And here I thought web apps were still limited to cookies for data storage. However, like cookies, data stored in IndexedDB can be discarded by the user at any time. Therefore it is necessarily limited to short-term storage scenarios. Like a PWA running offline, tracking data to be uploaded to the server once connectivity is restored.

Since service workers run behind the scenes, outside the life cycle and scope of standard web app code, it can get tricky to debug problems. An entire section Tools and Debug is dedicated to discussion about it. Some of the tips are useful beyond PWAs, like port forwarding from development desktop to Android physical devices. I think this would have helped me with my Compass web app, with its device-specific hardware.

Speaking of device-specific behavior, PWA offers the promise of a single codebase that can run across multiple devices, but this course is realistic about the fact that current browser implementations vary widely and require platform-specific knowledge. This gets worse the further we get away from core behavior. In the Enhancements section, there were more about how iOS Safari differs from Android Chrome than there were about behavior they had in common. What a mess.

From this "Learn PWA!" guide I've learned that PWAs start with a relatively simple core set of features (caching and network call interception) but can get very complex very quickly for ambitious developers who want to advanced features. Going hand-in-hand with that power is the potential for things to go very, very wrong. The one that made me grimace is the fact a misbehaving service worker could intercept F5 (refresh) preventing us from loading updated code. Aack! There's a lot to learn beyond this guide. The web.dev team offers a six-part hands-on PWA training course to supplement this guide, and of course there are other websites out there with additional resources.

It seems to me that PWA & related API were designed to offer maximum flexibility. Which is why a web app author is responsible for their own service worker so they can do exactly what they need in the context of their web app. However, in practice most web apps will be very similar. In order to minimize people copying and pasting code from random StackOverflow pages, the Chrome team has built the Workbox library to deliver code implementing popular behavior in a single library. This is useful. Furthermore, many web application frameworks have their own libraries for turning their applications into PWAs. Given my brief exposure to Angular, my next stop is to read up on Angular's PWA library.