Telerik blogs

As a developer I approach new platform features with a healthy amount of skepticism. You don’t have to look too far into this blog’s archives to find me complaining about the Apple Watch, web components, and plenty of other trendy technologies.

The latest of these trendy technologies seems to be progressive web apps, which the greater web community — most notably Google — has been pushing heavily over the last few months. I’ll defer to an article from Alex Russell for a thorough explanation of what progressive web apps are, but succinctly, progressive web apps are web apps that use a number of the web’s newest features, such as manifests, service worker, and others, to make web apps feel more like native apps.

The recent Chrome Dev Summit, and its numerous talks on progressive web apps finally convinced me to dive in myself. In this article, I’ll give my thoughts on progressive web apps from the firsthand experience of building one. I’ll discuss what I like, what I don’t like, and what I think progressive web apps mean for the future of the web. Let’s start with a quick discussion of what you need to do to build a progressive web app today.

Building a Progressive Web App

At a high level, for a web app to be considered “progressive” it must do three things:

  • Register a service worker — a series of APIs championed by Google that allows for offline access, web push notifications, and more.
  • Run on HTTPS, which is a hard requirement imposed by the service workers spec to prevent man-in-the-middle attacks.
  • Create an app manifest file, which specifies a bunch of information about your app such as its name.

My blog,, did none of these three things, so I figured upgrading it would be an excellent opportunity to try out the process firsthand. I won’t go over the steps in detail, but I will point out a number of guides that helped me tremendously:

In the same spirit of openness, here are the manifest.json and service-worker.js files I’m using to make my blog a progressive web app. Feel free to refer to them and copy and paste anything that you'd like.

With those files in place my blog now has two pretty awesome features:

  • 1) Offline support. You can read any previously viewed articles on my blog without a network connection. Also, if you attempt to read a new article while offline I display an offline page rather than failing altogether.
  • 2) App install banners: With an app manifest in place, Chrome for Android and Opera for Android now prompt users to install my blog as an app on their device’s home screen. The screenshot below shows the workflow in Chrome for Android:


Note: Chrome and Opera have evolving algorithms for how often to show the banner you see in the first screenshot above. Currently Chrome’s algorithm requires two separate visits to the site. You can force the banner to appear by visiting chrome://flags on your device and enabling the Bypass user engagement checks flag.

Although my blog is relatively simple, you can see the potential that these APIs offer. Imagine if Facebook or Twitter’s mobile web sites saved your feed so you could view it offline like their native apps do. Or if news publications removed their desperate calls for users to install their native apps with these browser-implemented install banners.

There’s a lot of potential here, but are these APIs ready for the average company to try out today? Let’s start that discussion with a look at browser support.

What About Other Browsers?

For a browser to support progressive web apps, the browser must implement the service worker and web app manifest specifications, and currently Chromium-based browsers (i.e. Chrome, Opera, Chrome for Android, and so forth) are the only browsers to support both. As for the other browsers:

This support situation seems rather negative, and yes, it could easily be years before these features make their way to iOS, especially considering mentions like this in a recently released 5-year plan from the WebKit team:

But don’t close the tab quite yet, because this poor support situation doesn’t matter as much as you may think it does. In fact, the single biggest reason I’m excited about progressive web apps is because they were designed with one of the web’s defining characteristics in mind: graceful degradation.

The Good: Graceful Degradation

Remember how I had to add two files to my blog to make it into a progressive app? What happens to those files in a browser that doesn’t support service workers or web app manifests? Absolutely nothing. The files are simply ignored.

This is refreshing because so many of the web’s latest features have not had this sort of elegant fallback. Yes, polyfills are a thing, but many of the web platform’s recent APIs aren't the sort of things that can be easily polyfilled — flexbox, pointer events, and cough cough web components come to mind.

And the simple truth is, there are a lot of web developers that can’t take non-graceful-degradation-friendly APIs seriously until those features reach each and every one of their supported browsers. Therefore if one browser, most commonly Safari nowadays, chooses not to implement an API, that browser is essentially holding that feature hostage from the majority of web developers.

Let’s take web components as an example. If you chose to go all in with web components in 2013, you chose to use poor performing polyfills in many browsers in the hope that the browser support situation would improve, and for the most part, it hasn’t (although the performance of the polyfills has).

But progressive web apps are different. Unlike web components, the only compelling reason not to implement these APIs in your apps today is the time and effort involved in writing and maintaining the necessary code.

The Bad: High Barrier to Entry

Although progressive web apps have the potential to add a lot of very useful functionality to the average web app, one thing I believe will hurt their adoption is the relatively high barrier to entry that these APIs present, starting with HTTPS.

I think by now most developers understand the importance of using HTTPS, including privacy, better performance with HTTP/2, and even higher rankings in Google searches. But that doesn’t change the reality that many sites — including a staggering number of prominent ones — have yet to make the switch to use HTTPS everywhere. Even doesn’t redirect HTTP traffic to HTTPS. Seriously, Amazon.

Initiatives such as Let’s Encrypt are attempting to lower the barrier to entry by providing free certificates. But the truth is in many organizations, especially larger ones, the average developer that understands HTTPS doesn’t have the ability to simply install a certificate on a server. Instead they must fight an often futile battle against red tape to get the job done.

And with progressive web apps, even once you have the HTTPS requirement down, the low-level nature of the service worker APIs, although spectacular in that they make a whole lot possible, will take developers a considerable amount of time to learn and understand. Resources like Jake Archibald’s offline cookbook are a great start, but many developers simply won’t want to write this boilerplate code themselves.

Over time I think we’ll eventually see frameworks integrate this offline suppport directly. Imagine an Angular router that is smart enough to work offline, a WordPress plugin that installs the necessary service worker and app manifest file automatically, or a Kendo UI spreadsheet widget that synchronizes offline changes to the server, even after the user closes the tab.

I think these things are coming, but for now the low-level nature of the service worker APIs means that if you want to build a progressive web app, you have to be prepared to roll up your sleeves. And I think this high barrier to entry matters, because, in my opinion, the single biggest barrier to progressive web app adoption is overcoming user expectations.

The Future of Progressive Web Apps

As developers we understand the nuances of the web as well as our mobile devices, but the average user does not. There are a couple big open UX questions for me when it comes to progressive web apps:

  • Will users trust the natively implemented “Add to home screen” button, especially in a web filled with so many custom versions of this same sort of functionality?
  • Will users be confused that web apps on their home screen aren’t truly native apps? That is, although web apps will appear on a user’s home screen with icons, they will not appear in app stores or lists of all applications installed on the user’s device.

I think these are UX challenges that can be overcome, but only with a sufficient number of sites actually using the progressive app APIs. A user may not trust a “Add to home screen” callout the first time, but by the fourth time I would expect the user to realize the prompt is coming from the browser itself, and worth trying out.

Therefore progressive web apps are subject to the same chicken-and-egg conundrum that plagues a lot of technologies. Users may not trust and use these apps until a sufficient number of sites leverage the progressive web app APIs. But large web sites may not want to implement those same APIs until there are a sufficient number of users that will actually "install" their web apps.

Because of the graceful-degradation-friendly design of progressive web apps, though, I remain optimistic. Almost every web app would benefit from adding a service worker to allow for some sort of offline access, even if it's just for displaying an offline error page. Plus, with the costs of acquiring mobile app users skyrocketing, a lot of businesses could stand to take a chance using the progressive web APIs to grow their user base.

Chrome for Android also offers a rather slick mechanism for prompting to download native Android apps from Google Play, which is an appealing alternative to building a custom banner to plug your Android app.

So if you work on a web app today, especially one that already has HTTPS setup, I would encourage you to take the time to turn your site into a progressive web app. Build a service worker, create an app manifest file, and participate in the future of the web.

Header image courtesy of Elena Flecha

TJ VanToll
About the Author

TJ VanToll

TJ VanToll is a frontend developer, author, and a former principal developer advocate for Progress.


Comments are disabled in preview mode.