Progressive Web Apps: The next big thing?
The What, Why and How of Progressive Web Apps
Progressive web apps, another buzzword in the development world that has been gaining a lot of traction for some time now. Is it really something that could be “Game Changing” or is it just another fad that will die soon? Let’s see if we can figure it out.
Before we start talking about Progressive Web Apps(PWAs), let’s briefly talk about the two main types of apps that currently dominate the arena.
- Web Apps: Served through the browsers, they work across the devices, independent of any single company or platform. It’s possible to search it and share what you’ve found with anyone, anywhere.
- Native Apps: Apps built keeping a single platform in mind, like Android apps or IOS apps or desktop apps. They provide superior user experience, and some work regardless of network connection. They can read and write files from the local file system, access device’s hardware and data, give push notifications and much more.
Each of these apps have some pros and some cons. While web apps provide superior reach and independence (which native apps can only dream of), they cannot match the features and the experience of a native app. I mean, who in their right mind would prefer to open the browser on their mobile phones to check Instagram when you have that handy little app right on your home screens.
Enter Progressive Web Apps. The aim is to create a Web App, that feels and runs like a native app on all the devices. And no, I don’t just mean that the apps will be responsive. We’re talking about matching all the features of a native app, while holding on to the strengths of a web app.
This essentially means that the PWAs are able to
- Serve data offline
- Give push notifications
- Install on home screen
- Access device hardware
- Background sync
And all this with a Single Codebase!
Pretty neat, right?
MDN says that there are some principles which a PWA must try to follow. An ideal PWA should have all of these features listed below.
Discoverable, so the contents can be found through search engines.
Installable, so it can be available on the device’s home screen or app launcher.
Linkable, so you can share it by sending a URL.
Network independent, so it works offline or with a poor network connection.
Progressive, so it’s still usable on a basic level on older browsers, but fully-functional on the latest ones.
Re-engageable, so it’s able to send notifications whenever there’s new content available.
Responsive, so it’s usable on any device with a screen and a browser — mobile phones, tablets, laptops, TVs, refrigerators, etc.
Safe, so the connections between the user, the app, and your server are secured against any third parties trying to get access to sensitive data.
So, they sound really cool and “Game changing”, but how do you convert a Web app to a Progressive web app?
There are some building blocks of a PWA that are absolutely necessary.
Brilliant, you replace a single confusing term with three more!
We’ll dive slightly deeper into what these three things are, but know that these are the building blocks of every PWA and that without all these, it’s just another website.
- Secure Contexts: The web application must be served over a secure network. HTTP won’t do here because most of the features related to a PWA such as geolocation and service workers are available only when the app has been loaded using HTTPS. Being secure, therefore is one of the requirements of a PWA.
- Manifest File: A JSON file that controls how your app appears to the user and ensures that your app is discoverable. It describes all the details necessary to transform the website into an app-like format. It decides how the app would look and behave when it is installed onto a device.
- Service Workers: A Service worker is the heart of a PWA. It is just another JS file which runs on a separate thread from our main JS file(that controls and modifies the DOM), because of which it is completely independent from the rest of the app. It can intercept network requests, save and retrieve resources from the cache(to provide some offline functionality), and deliver push notifications.
Okay, enough with the theory. Start building something!
We’ll try to convert a simple website into a PWA using the 3 things we talked about earlier.
I’ll be using this To-Do-List app (cliché?) as a starting point, but you can follow along with almost any web project of your own.
Most of the steps will be generic and you can use these to setup a PWA in almost any use case in the future.
But, let’s talk about this one last thing called Lighthouse before starting.
Lighthouse is an open-source, automated tool for improving the quality of web pages. You can run it against any web page, public or requiring authentication. It has audits for performance, accessibility, progressive web apps, SEO and more.
If you are on Chrome, open your dev tools, where you will find a tab named audit. I am using Brave, where I had a tab named Lighthouse(as you can see in the images below). There’s also an extension available for this tool in case you are running into some problems with your browser.
Check this page out for more info.
We’ll be using this from time to time in order to check how much of a PWA our app is. Let’s audit the hosted version of the app.
In many of the warnings above, you can see that no manifest was fetched! Let’s start with that. Setup a server to run your app locally and then continue.
Create a file named manifest.json in the app’s root directory and add the following code to it.
{
"name": "To Do List 2.0",
"short_name": "To Do List",
"start_url": "/index.html",
"display": "standalone",
"background_color": "#FFE9D2",
"theme_color": "#FFE1C4",
"orientation": "portrait",
"icons": [
{
"src": "icons/manifest-icon-192.png",
"sizes": "192x192",
"type": "image/png",
"purpose": "maskable any"
},
{
"src": "icons/manifest-icon-512.png",
"sizes": "512x512",
"type": "image/png",
"purpose": "maskable any"
}
]
}Also, add this line of code in index.html file to point it to the manifest file.
<link rel="manifest" href="manifest.json" />Okay, but who’s going to explain all this code?
Some key points here. These are some of the essential fields required by the browser to identify your app as a PWA. I’ll list out some non obvious ones and their use.
- start_url: Tells the device which page to load on startup on the installed app.
- display: Tells the device how your app should be presented to the user. “standalone” display means the installed app would look just like a native app, with no browser menus, offering a standalone experience.
- background_color: The background color specified here is used for the splash screen (which is auto generated from the manifest file).
- theme_color: Sets the overall theme of the installed app.
- icons: Points to the icons to be used by the installed app for the splash screen, home screen, installer, etc. At least two sizes(192x192 and 512x512) are required for the app.
Many online tools available for generating different icon sizes and types.
Read more about manifests here.
Now, onto the Service Worker(SW), which will contain all the logical aspects of our PWA. Before starting using a SW, it must be registered with the browser. See this page for more information about the SW lifecycle(highly recommended).
I have created a separate file for registering our service worker. It’s called app.js and it is present at the root of the app.
if ("serviceWorker" in navigator) { //checks if browser supports SWs
navigator.serviceWorker
.register("./sw.js")
.then((reg) => {
console.log("Service worker registered", reg);
})
.catch((err) => {
console.log("Service worker could not be registered", err);
});
}Also, don’t forget to add the following script tag to index.html file
<script src="app.js" charset="utf-8"></script>The app.js code checks if the browser supports Service Workers, and if it does, then it registers ours with it.
Our app will have some offline capabilities, for which we will use the browser cache. In our service worker, we will tell the browser to store some of the pages/resources offline in the cache, so that whenever a request is sent to those pages/resources, we will serve them from the cache, rather than asking the server for them.
Create a sw.js file in your project’s root directory and add the following code to it.
const staticCache = "site-cache";
const assets = [
"/",
"/index.html",
"/Assets/js/todos.js",
"/Assets/css/todos.css",
"/Assets/js/lib/jquery-3.4.1.js",
"/icons",
];
//service worker install event
self.addEventListener("install", (evt) => {
console.log("Service worker installed");
evt.waitUntil(
caches.open(staticCache).then((cache) => {
cache.addAll(assets);
})
);
});//fetch event
self.addEventListener("fetch", (evt) => {
console.log("Fetch event", evt);
evt.respondWith(
caches.match(evt.request).then((res) => {
return res || fetch(evt.request);
})
);
});
Here, when the SW is installed in our browser, it opens a cache field named “site-cache” and caches the resources and pages specified in the assets array.
The fetch event is triggered whenever the app sends a network request. It helps the SW to redirect or modify the requests as needed. This is the reason why SWs require HTTPS because they act like a middleman for all the requests our app sends, and can be prone to attacks on an unsecure channel.
Above, the evt.respondWith method decides what to do with the request. It checks if the resources requested are available in the cache.
caches.match(evt.request).then((res) => {
return res || fetch(evt.request);
})If they are, the response (res) from the cache is returned, else the request is sent to the server.
That is all it takes to setup offline functionality in your app. Although the data you store may vary, the logic remains the same.
Now, with all this done, let’s audit our app again. Your app would be running on a local server right now which is an exception to the HTTPS only rule of PWAs.
There you go. All the tests pass, except for the HTTPS redirection which is handled on the server side, which means our app is now a PWA. The app will now be recognized by the browser as a PWA and it will automatically give the user an option to install the app to their device.
Go ahead and host your app anywhere you prefer(my advice is to use Github pages or Netlify, both are easy to use and get you setup pretty fast). Navigate to that link on your mobile phones to test whether the app is installable or not.
Do know that this is only a beginner’s guide at PWAs and there’s a lot more to them than what we discussed. That being said, I hope that the article was informative and you have your first PWA set up.
