At this moment you’ve already read, attended a conference or at least heard about PWAs, but what’s all the fuss about? We’ll explain this in a coffee break-sized post.

Let’s start from the beginning. PWA stands for Progressive Web Applications. We are already familiar with concepts like Single Page Applications or Multiple Page Applications, but this new player is all about progressiveness.

We rush to google this new concept just to find out that most of the official documentation comes from google itself. After reading the first results page, it’s clear that a PWA is nothing other than an offline-first website. So, its growth in content is progressive, downloading new data when it’s requested and available. And now it’s clear what the P in PWA means.

Sorry, you said offline-first website?
Yes, this new breed of website makes use of the latest technologies such as HTTP/2 protocol, Service Workers and manifest.json. These technologies are used to download a version of the website, with some chunks of code remaining forever in the client browser. These chunks will contain the logic needed to both request and push data from the server. But let’s dive a little deeper into the workings of these new players.

Service Worker.
A service worker is a script that your browser runs in the background, separate from a web page, opening the door to features that don’t need a web page or user interaction.
Can’t argue with a brief and clear explanation provided by google itself.

Manifest
The manifest.json is a javascript object notation file that holds metadata needed by the browser to create a shortcut, add a title, and provide a splash screen when installing a website in our mobile’s home screen. It basically mimics the experience of installing a native application using the content provided in the manifest file.

How do I start with PWA’s?

At the moment, many of the mainstream front end frameworks have command line installers that scaffold a pwa with a service worker and manifest json.

• create-react-app scaffolds a react-based pwa
• vue-cli with the –mobile flag generates the same using vuejs
• also, polymer has its own starter kit that generates a pwa

So it doesn’t matter which framework you are comfortable using since there’s a cli for every developer.

I’ve read about a something called PRPL, what’s that about?
PRPL is a pattern for structuring and developing PWA’s, emphasizing performance and minimum time to responsiveness.

PRPL stands for:
Push critical resources to the initial URL.
Render the initial route.
Pre-cache remaining routes.
Lazy-load and create remaining routes on demand.

These concepts are the holy grail for developing a solid PWA.

How do I audit and debug?

There are several tools to audit a website, but there’s one that specifically targets progressiveness in your webapp. The Lighthouse Chrome plugin not only audits a website, it runs a suite of tests (throttling network speed, measures performance, etc.) and provides a report at the end with all the information and opportunities for improvement.

To debug, there are some new tabs in the Chrome inspector window: the Performance tab and the Application tab. The first one shows a timeline of every task the browser has executed since the first request, providing valuable data about the critical path and what’s slowing it.

The latter provides useful information about service workers installed, allowing the developer to always request a new service worker every time the webpage is loaded so he’s certain he’s running the latest version of it. It also provides live information about the manifest.json.

So, is this better than native applications?

Let me correct that question: PWAs are different from native applications. Since they are just offline websites, they’re developed using HTML, CSS and Javascript, so they have access to the same API’s that a regular website is allowed to access. There’s still some hardware that is not accessible for a website, but it’s just a matter of time until the HTML5 APIs adds more support and browsers standardize it. Performance-wise, there are no issues when comparing Native apps with PWAs.

But always keep in mind the major issue that Progressive Web Apps have today, the elephant in the room: Support.

As of today, our state-of-the-art PWA will have a seamless experience only in the Chrome browser running on Android devices.

It’s all clear now. But what about the future?

The main game players are migrating their lite apps to PWA’s. This makes sense since it allows them to have a team of developers working on the webapp, reusing the same team on the website if the workload is low regarding the app. Twitter’s mobile page is already a PWA just to mention an example. But since PWA’s are still not widely supported it’s not a safe bet to develop PWA’s as the main mobile experience if the app’s target audience is broader than just Android users.

—
This new trend is still in its early stages at the moment, but it enables developers to engage users using the same website as a mobile app instead of installing a proper app. It also allows developers to specialize in web languages instead of learning specific languages or frameworks for each mobile platform.

The service worker is a new concept to explore and support is the big throwback here but it’s just a matter of time for the other browsers to catch up. New issues will certainly appear, such as optimization of assets or parallel requests and uncertainty but that’s a headache we should suffer only when the time comes.

While there are many tutorials on the web, I want to share our own. At Making Sense we have a series of UX Workshops, and in this opportunity, we dig a little deeper into this concept (Spanish version).

It’s an exciting moment to be a UX developer and face the upcoming challenges.

Stay tuned!