Building Progressive Web Apps

Chapter 1. Introducing Progressive Web Apps

Words are pale shadows of forgotten names. As names have power, words have power. Words can light fires in the minds of men. Words can wring tears from the hardest hearts. There are seven words that will make a person love you. There are ten words that will break a strong man’s will. But a word is nothing but a painting of a fire. A name is the fire itself.

Patrick Rothfuss, The Name of the Wind

Once every few years, the web experiences a pivotal moment. A moment where several separate technologies click together and make a splash in the public’s eye. These may be existing technologies that have been around for years or newer ones that have just now gained browser support. But to the outside observer, it seems like there is one shining moment in which the web suddenly takes a leap forward.

We saw this happen with Ajax, which one day exploded seemingly out of nowhere (despite much of the underlying technology, such as XMLHttpRequest being around for years) and changed our notion of the web as a series of linked, mostly static, pages.

Ajax itself was a part of the Web 2.0 revolution, another powerful name that seemingly popped out of nowhere in 2004 and exploded overnight.

A few years later, mobile-first came into the spotlight and signaled a shift in how we look at web development. By giving a name to a set of design philosophies, these two words gained incredible power. With just two words we could shout out that the days of the user sitting in front of her home computer with a 20-inch monitor and a cable connecting it to the wall were over. With two words we understood that it was time to change the way we approach web development.

Such moments often appear not when a technology is born, but when it is named.

Names have such power. They let us grasp new ideas. They let us discuss new concepts. They draw our attention to a storm that has been brewing under the surface.

A similarly huge shift is happening right now. Luckily, it has a name.¹

The Web Strikes Back

Progressive web apps are a new breed of web apps that combine the benefits of a native app with the low friction of the web.

Progressive web apps start off as simple websites, but as the user engages with them, they progressively acquire new powers. They transform from a website into something much more like a traditional, native app.

Imagine waking up in the morning, grabbing your phone, and visiting the website of your local train company. You quickly check the schedule of the train that will get you to work, close your browser, and put the phone back in your pocket. At the end of that day, you visit the site again and check when the next train departs (not even noticing that the elevator you are riding has no cell reception because the train company’s site now works even when you are offline). The next day when you visit the website again, your browser asks you if you would like to add a shortcut to it on your homescreen, and you happily agree. Later that day when you launch the site from an icon on your homescreen, it lets you know that due to some construction work, delays may be possible and asks you if you would like to receive notifications about future changes to your commute. The next morning, as you are waking up, you receive a notification on your phone that your train has a 15-minute delay. You hit the snooze button on your alarm and gain a few more precious moments of sleep.

What started as a simple website has slowly acquired new powers until it was just as capable as any native app on your phone. Instead of trying to send you to the app store, hoping you will install their app, the train company has earned a permanent place on your phone—one step at a time.

This new progressive model replaces the binary installed/not installed nature of native apps. Progressive web apps build trust with their users and acquire new powers as they are needed.

You may be asking yourself, how is this an improvement over native apps? Why shouldn’t we just stick with what works? Well, unless you are one of the lucky few, you already know that what we have right now isn’t working. Every year, the chances of users installing your app are growing smaller and smaller. Every year, the cost of acquiring new users balloons. Every year, keeping your users engaged gets harder and harder.

The Current Mobile Landscape

When the first iPhone was launched in 2007, its killer feature was allowing you to browse websites on your phone. When mobile apps were introduced a year later, developers were finally able to break beyond the limited functionality of the web page (while taking on many new limitations, thanks to the introduction of the App Store).

With features like advanced graphics, geolocation, push notifications, offline availability, homescreen icons, and more, the web seemed to pale in comparison in the eyes of many developers. Native apps took over the world (and our phones) by storm.

But this trend is shifting. While we spend more time than ever before on our phones and using mobile apps, we spend that time in an increasingly smaller number of apps. Users are installing fewer apps and using only a handful of the ones they have installed. If your app is one of the top 10 apps in the app store, you are probably doing fine. But trying to break into the market with a new app is near impossible, not to mention costly.

How We Behave on Mobile

According to a 2016 comScore report, the average person spends 84% of his time on mobile devices using just the top 5 most popular apps. I’m sorry to say, these are not your apps. On tablets that number is even higher, with 95% of user time spent in the top 5 apps.

The same report also presents figures showing that it is much easier to reach a large audience on a mobile site than in a native app. There are close to 600 mobile web properties that reach audiences larger than 5 million visitors—nearly 4.5 times greater than the number of native apps with similar audiences. The top 1,000 mobile web properties have audiences that are almost 3 times the size of the top 1,000, apps and their audiences are growing twice as fast as native app audiences.

Getting users to install and use your app means surviving a vicious funnel. Users need to find out about your site (through traditional online advertising or on your website). They then have to visit your page on the app store. Then they need to click install. They need to agree to give the app different permissions. Then they need to wait for the app to download and install. Finally, they need to actually launch the app at least once and maybe even use it.

This funnel may not seem too bad when you are installing an app you know and love, such as Twitter or Facebook. But a number of studies have shown that an average of 20% of users are lost during every step of this funnel. It is not uncommon for app developers to pay for banner clicks, only to discover that less than 20% of those users actually launched the app.

Sites have become so desperate to get you to install their app that they have resorted to a new method of advertising. You know the one: you arrive at a site looking to read a short article or find out tomorrow’s weather. The info is right there, within your grasp, but then a banner pops up on your screen blocking the very content you want. It asks you if you would like to install an app instead of reading the content that is already right in front of your eyes.

Some people call these a full-page interstitial ad. I prefer a shorter name: the door slam (Figure 1-1). For more details on the effects and the ineffectiveness of full-page interstitial ads, see Appendix B.

Figure 1-1. A common door slam

It is a brutal, costly battle to get a user to install your app on her phone. But the edge that native apps held over the web meant app developers were willing to endure (and inflict) much for each app install.

A native app, as opposed to a traditional website, has a life beyond the short time a user spends with it when he first discovers it, and the time (sometimes seconds later) when he wanders away. Once installed, apps have a permanent place on your homescreen. They can reach out to you with notifications at any time and remind you of their existence. They give their developers many chances to try and get a return on their investment over the long lifetime of their app.

But with the introduction of progressive web apps, the tide is finally turning. The edge granted by these superpowers, which have so far been the exclusive domain of native apps, is now available to web apps. Couple that with the low friction, one-step funnel of the web (clicking a link versus installing an app), and you can see why users, web developers, and businesses have much to gain from embracing progressive web apps.

The Progressive Web App Advantage

With the additional superpowers they introduce, progressive web apps fulfill many of the expectations we have from native apps.

Here are a few of the benefits we will cover in this book:

Availability regardless of connection

Progressive web apps are not dependent on the user’s connection like traditional websites are. When a user visits a progressive web app, it will register a service worker (see “The Tab, the Web, and the Service Worker”) that can detect and react to changes in the user’s connection. It can provide a fully featured user experience for users who are offline, online, or suffering from an unreliable connection.

Your users could be using your progressive web app while flying over the Atlantic, and even take actions (e.g., posting messages, RSVPing for events, or commenting on posts) knowing that their actions will complete as soon as they go back online—even if they close your app and their browser. See Chapter 7 for more details.

Progressive web apps introduce a level of reliability, and in turn, gain the user’s trust to a level that was so far only given to native apps. A user knows she can open the WhatsApp app at any time, write a quick message, and close her phone without worrying about the current state of her connection. The web hasn’t enjoyed this level of trust until now, which is one of the reasons users often preferred native apps.

Fast load times

Using service workers, we can create sites that launch in an instant, whether the user has a blazing fast connection, an unreliable 2G connection, or even no connection at all. Sites can load in milliseconds, much faster than anything we have experienced on the web before, and often even faster than native apps. In Chapter 5 we will learn how to achieve this, and explore the offline-first philosophy.

Push notifications

Progressive web apps can send notifications to their users (even days after they left the site). These notifications offer a great chance to re-engage with your users and remind them to come back to your app. Progressive web app notifications have a completely native feel and are indistinguishable from native app notifications. See Chapter 10 for more on push notifications.

Homescreen shortcut

Once a user has shown interest in a progressive web app, the browser will automatically suggest that he add a shortcut to his homescreen—completely indistinguishable from any native app (Figure 1-2). See Chapter 9 to learn how to grab prime real estate on the user’s homescreen.

Figure 1-2. App install banner

Native look

Progressive web apps launched from the homescreen can have an entirely native, app-like look. They can have a splash screen as they are loading. They can launch in full-screen mode, without the browser and phone UI around them. They can even lock themselves to a specific screen orientation (a vital requirement for games).

See Chapter 9 for details.

Lyft—More Platforms, More Riders

Beyond their user experience benefits, progressive web apps offer additional benefits to the businesses that adopt them.

Lyft, the popular ride-hailing service, is a company that is completely reliant on its mobile app for revenue.

As part of Lyft’s ongoing efforts to reach more users, the company found itself having to support a growing number of devices and mobile OS versions. As the app evolved, Lyft had to deprecate support for older iOS and Android versions or face growing maintenance costs. Rather than giving up on these potential clients (which made up 8% of iOS users, and 3% of Android users), Lyft built a progressive web app.

By adopting progressive web apps, the team at Lyft was able to decrease the technical and operational costs associated with supporting multiple apps and devices. More importantly, they were able to reach new users on iOS and Android, as well as audiences they previously ignored: Windows Mobile and Amazon Fire users.

The Tab, the Web, and the Service Worker

At the heart of every progressive web app is the service worker.

Service workers present a shift in how we look at web development. Taking a few minutes to understand where they fit in is vital to understanding their potential.

Before service workers, we had code running either on the server or in the browser window. Service workers introduce another layer.

A service worker is a script that can be registered to control one or more pages of your site. Once installed, a service worker sits outside of any single browser window or tab.

From this place, a service worker can listen and act on events from all pages under its control. Events such as requests for files from the web can be intercepted, modified, passed on, and returned to the page (Figure 1-3).

Figure 1-3. The tab, the web, and the service worker

This means that there is a layer between the page and the web that can respond to requests independently of a network connection. A layer that works even when the user is offline. This layer can detect an offline state or slow responses from the server and return cached content instead (Figure 1-4).

Figure 1-4. Pages communicating with a service worker while the user is offline

Taking this logic a step further, it means that even if the user closed all the tabs running your app in her browser, there is still a layer that can communicate with your server (Figure 1-5). It can receive and display push notifications, or make sure any actions performed by the user get delivered to the server (even if she stepped into the elevator just as she took that action and then closed your app before regaining connectivity).

Figure 1-5. The service worker communicating with a server after a user has left the page

You can see why service workers are at the heart of every progressive web app. Their persistent nature allows progressive web apps to fulfill our expectations of what an app should do. They are the missing link between what only native apps could do and what modern progressive web apps can do.

But perhaps their greatest power is that service workers are simply JavaScript files. They are written just like any other JavaScript code you have been writing for years.

As developers, the benefits of understanding service workers and the associated technologies covered in this book are huge. They allow us to leverage our existing knowledge of web technologies, such as JavaScript, HTML, and CSS, to write web apps that can truly compete with and even surpass native mobile apps.

¹ Or rather, luckily, Alex Russel and Frances Berriman had dinner together one night and came up with a name. See Alex Russel’s blog post, “Progressive Web Apps: Escaping Tabs Without Losing Our Soul”.