As a developer, I approach new platform features with a healthy amount of skepticism. A trendy technology which the greater web community has been pushing heavily over the last few months is progressive web apps. I’ll defer to an article from Google developer Alex Russell for a thorough explanation of progressive web apps, but succinctly, progressive web apps are apps that use many of the web’s newest features, such as manifests and service workers, to make them feel more like native apps.
There are a few things that developers should keep in mind when building a progressive web app:
Building a Progressive Web App
For a web app to be considered “progressive” it must do three things:
My blog had previously done none of these three things, so upgrading it was an opportunity to try out the process firsthand. Two guides helped me tremendously:
With those files in place my blog now has two excellent features:
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. There’s a lot of potential here, but are these APIs ready for the average company to try out today?
What About Other Browsers?
For a browser to support progressive web apps, it must implement the service worker and web app manifest specifications, and currently Chromium-based browsers (i.e. Chrome, Opera, Chrome for Android) are the only browsers to support both.
This support situation seems rather negative but don’t close the tab quite yet, because this doesn’t matter as much as you may think it does. In fact, the 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 added two files to my blog to make it into a progressive app? Well what happens to those files in a browser that isn’t supported? Nothing - the files are simply ignored.
This is refreshing because many of the web’s latest features have not had this sort of elegant fallback. The simple truth of the matter is many web developers won’t take non-graceful-degradation-friendly APIs seriously until those features reach all of their supported browsers. Therefore if one browser chooses not to implement an API, that browser is essentially holding that feature hostage from the majority of web developers.
The Bad: High Barrier to Entry
While progressive web apps have the potential to add useful functionality to the average web app, one thing that may hurt their adoption is the relatively high barrier to entry that these APIs present, starting with HTTPS.
While most developers understand the importance of using HTTPS, including privacy and better performance with HTTP/2, that doesn’t change the reality that many sites have yet to make the switch to use HTTPS everywhere. Initiatives including Let’s Encrypt are attempting to lower the barrier to entry by providing free certificates. But in many organizations, especially larger ones, the average developer doesn’t have the freedom to simply install a certificate on a server. Even once the HTTPS requirement is met, the low-level nature of the service worker APIs will take a considerable amount of time to learn and understand.
Over time, we’ll see frameworks begin to integrate offline support directly, but for now, if you want to build a progressive web app, you have to be prepared to roll up your sleeves. This high barrier to entry matters because the single biggest barrier to progressive web app adoption is overcoming user expectations.
The Future of Progressive Web Apps
While developers understand the nuances of the web and mobile devices, the average user does not. As a result, there are two major open UX questions around progressive web apps:
Progressive web apps are subject to the same chicken-and-egg conundrum that plagues many 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 APIs until a majority of users will actually “install” their web apps.
Still, I remain optimistic. Almost every web app would benefit from adding a service worker to allow for offline access, even if it’s just for displaying an offline error page. With the costs of acquiring mobile app users skyrocketing, most businesses could stand to take a chance using the progressive web APIs to grow their user base.
If you work on a web app today, I 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.
About the Author:
TJ VanToll is a Senior Developer Advocate for Telerik, a Progress company, a jQuery team member, and the author of jQuery UI in Action. TJ has more than a decade of web development experience—specializing in performance and the mobile web—and speaks about his research at conferences around the world.