Exploring Progressive Web Apps (5 Part Series)
This is the first of a series of articles about PWAs. We will start from the basics and then gradually move deeper into technical features and real case scenarios.
My goal is to provide, at each step, enough information without overwhelming you with too many details all at once.
Progressive Web Applications (PWAs) have become very popular in recent years and with good reason as they can not only improve performance, but also be accessible when the user is offline.
Without service workers...
...and with service workers:
A big difference, isn't it?
As a minimum, we can provide branded offline pages with the company logo and colors, or also include some static information like phone numbers or email addresses. Some companies go a step further, providing an offline game in case the user loses connectivity.
The attention of the user remains locked on the game until connectivity is restored, after which the user is automatically redirected to the requested page. Thanks to this approach the company has more chances of retaining a potential customer.
Nowadays almost all browsers support service workers:
IE11 is not invited to the party (in case you still work with it 😢).
A progressive web app is simply a web application that, thanks to modern web features, can provide a richer user experience, very similar to what a native app can deliver.
According to Google a PWA has the following features:
Progressive: If the user has an old browser (IE 11), the application will still work as a normal web app, without delivering any progressive function.
Works offline: With service workers we can decide which assets or data requests to cache and make available when the user is offline or on low quality networks.
Safe: Service workers can only be installed using a secure connection (HTTPS or localhost. We will discuss this in detail later).
Re-engage: Increases user re-engagement through push notifications. Push notifications work in the background, allowing us to reach our users even if the application is closed.
Installable: Thanks to the web app manifest a PWA can be installed on the user's device home screen.
Responsive: Fits any device: desktop, mobile or tablet.
pwastats.com collects several successful stories of companies from different fields that benefit from the adoption of PWAs for their business.
We saw how PWAs aim to deliver the same experience as native apps. However, there are functionalities we cannot still achieve, such as interacting with a phone's contacts list or sending an sms. On the other hand, many features are available nowadays which were unimaginable just a couple of years ago.
Did you know that we can make a device shake with the Vibration API?
We can pulse the vibration hardware once by specifying a single value:
It is also possible to provide an array of integers. They will be interpreted alternately as the number of milliseconds the device should vibrate and the number of milliseconds it should not:
window.navigator.vibrate([100, 50, 100]);
The method above will make the device vibrate for 100ms, then pause for 50ms, then vibrate again for another 100ms.
If no vibration hardware exists, then nothing will happen. This is a progressive approach that will work only on capable devices and will be silently ignored on others without crashes or performance deterioration.
On the site whatwebcando.today you can verify all the APIs currently available in modern browsers (you can check the support state for each API by clicking on it).
Let's analyse some other differences:
No need to go through the validation process of Apple or Play stores; once our PWA is deployed, it is immediately available to the public.
We deliver only one version. The users will automatically receive the latest version without being bothered with update requests.
If we have frontend developers working on our corporate website, with little extra effort they can also create also a PWA. This is not the case for mobile development, where we would need additional resources, because typically we need at least two mobile teams: one for iOS and one for Android (omitting Windows mobiles).
By definition, every page of a PWA has to be dynamically linkable. This is very important - especially for social media - as we can easily share our app pages without our recipients needing to have the same application installed on their side.
Regarding offline usage, perhaps the two alternate solutions are evenly matched. Service workers alone only allow the caching of GET requests, not POST or PUT requests, as these would change the server state. Many native apps only function with a stable internet connection, although some allow offline usage. In one of our future links, we will explore how we can remove this weakness of service workers and allow the caching of POST/PUT requests. So stay tuned!
We just saw before that modern APIs are allowing more and more interaction with the hardware of the device, but several functions are still missing and browsers support is limited. Therefore native apps are still the winners in this context.
Native apps were until recently still in the lead, but thanks to TWA (Trusted Web Activities), it is now possible to make our PWAs available in the Play Store. So, another step closer to native apps 😂
Progressive Web App:
- The app must be available on market quickly
- Limited budget available
- Several updates planned after go live
- Cross platform compatibility a requirement
- Speed and responsiveness key factors
- Use of a specific hardware device's features required
- The app must be integrated with other 3rd party applications
🎉 And that's it for the first part! 🎉
At the moment the topics I plan to describe have the following structure:
- In step 2 we will learn how to install a PWA on a user's device and the different options available to instruct the browser how to render our application.
Step 3 will describe 🔥
service workers🔥, different caching strategies and in which case we should use them.
- Step 4 will describe the tools available today to for creating PWAs. Some are independent from any JS frameworks, but we will also see how we can create a fully working PWA from scratch with Angular.
Step 5 we already briefly mentioned how service workers can only cache
GETrequests. In this post we will bring our PWA to the next level, allowing our application to enjoy full CRUD operations 💪.
- Step 6 will teach us how to re-engage our target users using push notifications.
Are there any other topics you would be interested in me covering? If so, please leave me a comment.