loading...
Cover image for A gentle introduction to Progressive Web Apps

A gentle introduction to Progressive Web Apps

paco_ita profile image Francesco Leardini Updated on ・6 min read

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.

Let's start our journey...

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...

   offline

...and with service workers:

sw-offline

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 the connectivity is restored and the requested content is automatically delivered. This is a clever approach allowing to retain a potential customer, that would have abandoned the website otherwise.
 

Browsers support

Nowadays almost all browsers support service workers:

sw-stats
source caniuse.com
 

IE11 is not invited to the party (in case you still work with it 😢).
 

A definition for PWA

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 users re-engagement through web notifications, that work in the background, allowing 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.

 

Inspiring resources

pwastats.com collects several successful stories of companies from different fields that benefit from the adoption of PWAs for their business.

pwastats.com


At the website pwa.rocks you can see many examples of PWAs.

Alt Text


Lastly you should also visit the hnpwa.com page. It lists a demo implementation of the Hacker News website implemented with various front-end frameworks and showing a comparison of the response time with a slow network connection.

Alt Text

Alt Text

Some of the results are really impressive and fully witnessing the potential of PWAs.
 

PWA or Native App...that's the question

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.

*(This is partially true, as Google is implementing a very new -at the time of writing- API, still in test phase, called Contact Picker API, providing the users a way to share contacts from their contact list with ease.)

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:

window.navigator.vibrate(100);

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 pause:

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.

support
This feature is currently not available for all browsers, though. This time also Safari and Edge have also not being invited to the party.

On the site whatwebcando.today you can verify all the Web APIs currently available with the browser you are currently using to access the page (you can check the support state for each API by clicking on it).

Let's analyse some other differences:

No waiting time for app review

    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.

Easy versions management

    We deliver only one version. The users will automatically receive the latest version without being bothered with update requests.

Developing costs

    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).

Shareable links

    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.

Offline usage

    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 it is possible to overcome this weakness and allow to caching also POST/PUT requests.

Limited access to hardware

    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.

Availability on stores

    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 😂
 

When to develop a PWA rather than a native app?

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  

Native app:

  • 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 GET requests. 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.

perfect

If you liked it so far, please leave some positive vibes ❤️ to pass me some energy for writing more articles!!
 
You can follow me on:
 
follow-me-twitter
 

Posted on by:

paco_ita profile

Francesco Leardini

@paco_ita

Software Engineer ∙ International speaker ∙ Focusing on Javascript, Angular, React and PWAs

Discussion

pic
Editor guide
 

Thanks! What do you think about the hybrid approach?

DEV's iOS and Android app are written with that approach, basically creating a shell around the web app:

ps. the link to pwastats.com is broken :)

 

Thanks for the hint about the link, fixed now 👍!

I am not familiar with the hybrid approach, I will make some researches about it.

However, as soon as we bring in natives apps (iOS/Android) wouldn't we lose some of the PWAs benefits in terms of reusing the same developers and reduce the time to market (skipping the store approval)?

 

However, as soon as we bring in natives apps (iOS/Android) wouldn't we lose some of the PWAs benefits in terms of reusing the same developers and reduce the time to market (skipping the store approval)?

I'm not the resident expert on the apps but the thing is they don't subtract anything from the PWA, you can still use that as it is. The goal is to be able to enhance it with native APIs in a limited set, this way you can get the best of both worlds without too much effort.

But yeah, it's more work than just having the PWA

Sounds good. I will look deeper into it. Thanks for giving the hint!!

 

Nice and good explained post!
I'll start reading the second part of the series...

 

Thanks for this article.

Given the limitations of older browsers like IE 11, how should a developer be building a PWA-enabled web app that is backwards compatible?

 

As IE11 does not support Service Worker and Cache API, you should implement the logic by scratch.

This means detecting when the client is offline and store some PUT/POST Requests in an Indexed dB in order to trigger them again once the user gets online again.

Indexed dB can also be used to cache some data and make it available even when offline.

I am not aware of polyfills for IE11, but before starting implementing a custom solution it might be worth to search for them.