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. You can follow the "#steps" in the title to know at which point of the journey you are.
My goal is to provide, at each step, enough information without overwhelming you with too many details all at once.
Progressive Web Applications (PWAs) became very popular in the last years and with good reason as they can not only improve performances, 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 colours, eventually some static information like phone numbers or email address. Some companies go even a step further though, providing an offline game in case the user loses his connectivity.
The attention remains locked to the game and, once the connectivity is restored, he will be automatically redirected to the requested page. Thanks to this approach the company has more chances to retain a potential customer.
Nowadays almost all browsers support service workers:
IE11 is not included into 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 close 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 be installed only using a secure connection (HTTPS or localhost, we will see this in detail later).
Re-engage: Increases users re-engagement through push notifications. Push notifications work in the background, therefore we can 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.
The web site pwastats.com collects several successful stories of companies from different fields that benefit from the adoption of PWAs for their business. I encourage you to visit their website to discover more details about it.
We saw how PWAs aim to deliver the same experience as native apps. However there are still functionalities we cannot achieve, like interacting with the phone agenda or sending sms. On the other side many features are nowadays available via browser and they were unimaginable just a couple of years ago.
Do you know that we can make a device shake with the Vibration API?
We can pulse the vibration hardware one time by specifying a single value:
It is also possible to provide an array of integers. It will be interpreted alternately as the number of milliseconds the device should vibrate and the number of milliseconds it should not be vibrating:
window.navigator.vibrate([100, 50, 100]);
The method above will make the device vibrate for 100ms, then pauses for 50ms before vibrating the device again for another 100ms.
If no vibration hardware exists, then nothing will happen. Again 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 available in modern browsers (you can check the support state for each API by clicking on it).
Let's analyse some other differences:
Not 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 to update our application.
If we have frontend developers working on the corporate website, with little extra efforts, we can reuse them to create also a PWA, while this is not the case for mobile development. Typically we need at least two mobile teams: one for iOS and one for Android (omitting Windows mobiles), translating in more resources needed.
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 that our recipients have the same application installed on their side.
On this side maybe the two solutions are even. Service workers, alone, allow to cache only GET requests, but not POST or PUT as they would change the server state. Many native apps also function only with a stable internet connection, but some allow also to be used offline. In one of the future links, we will explore how we can extend this weakness for service workers and allow to cache also POST/PUT requests, so stay tuned!
We just saw before as modern APIs allow more and more interaction with the hardware of the device, but still several are missing and the browsers support is not so wide yet. Therefore native apps are still the winner in this context.
So far even on this aspect native apps were leading, but recently thanks to TWA (Trusted Web Activities), it is possible to make our PWAs available in the Play Store. Hence another further step closer to native apps 😂
Progressive Web App when:
- The app must be available on market quickly
- Limited budget available
- Several updates planned after the go live
- Cross platform compatibility is a requirement
Native app when:
- Speed and responsiveness are key factors
- Specific use of the hardware device is 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 learn how to install a PWA on a user's device and the different options to instruct the browser on how to render our application.
Step 3 is going to describe 🔥
service workers🔥, different caching strategies and in which case we should use them.
- Step 4 will show the tools available to create PWAs. Some of them are independent from any JS frameworks, but we will also see how we can create a fully working PWA from zero with Angular.
Step 5 We already briefly mentioned how service workers can only cache
GETrequests. However in this post we will bring our PWA to a next level, allowing to use the application with full CRUD operations 💪.
- Step 6 will teach us how to re-engage our target users using push notifications.
Are there further topics you would be interested in? If so, please leave a comment and I will try to cover them as well.