Chrome Developer Summit Recap

The Chrome Developer Summit told a dramatic story about the mobile web. If this story a had main character, there is no doubt that it was Progressive Web Apps.

Alex Russell at the Chrome Dev Summit.

If you’re wondering what Progressive Web Apps are, you’re not alone.

Progressive Web Apps are modern, mobile first, offline web apps, that can compete with the best of those on native.

Progressive Web Apps are meant to be the new standard of the mobile web. They combine the engagement of native apps with the reach of the web.

Make no mistake, Progressive Web Apps are a concrete part of the Web’s platform. This is not just an idea or a concept. Progressive Web Apps have hard criteria with serious benefits. The Chrome Developer Summit was intentionally set up to tell the story of Progressive Web Apps.

Progressive Web Apps

“Why will anything I say work, when these didn’t?”

This question asked by Alex Russell was in reference to other technologies like Apache Cordova. His answer was simple. It’s the power of friction. The technology in these apps are web based but the end product is not. “If you can’t link to it, it’s not part of the web.”

These words embody what makes Progressive Web Apps different from any hybrid or even native counterpart. The native app install process is a long road to actually using the app. The user has to discover your app, then get to the app store, download the app, open it, accept permissions, and usually create an account. With the web, it’s just a link and a page load.

The web’s secret weapon is low friction.

Progressive Web Apps may start out as tabs, but they can emerge from the primordial soup of the browser. They can become more than a tab and join the ranks of the home screen. This app “install” is low friction compared to the native app install process.

Progressive Web App Checklist

For an app the qualify as a Progressive Web App, it must meet four qualifications:

1. Manifest. The app must have a valid manifest with required properties. This uses the Web Manifest Format.
2. ServiceWorker. The app needs to load offline.
3. HTTPS. The site must be of Secure Origin.
4. Engagement. To get the Web App Install Banner (the “Add to Homescreen” banner), the user must visit at least twice and for 5 minutes. This banner doesn’t show up until these two visits. This decreases the spammy-ness.

When Progressive Web Apps are launched they open like a real app. They have splash screens, the app opens in fullscreen given back the real estate taken by the browser’s status bar. These apps have the same “appy” feel as those on native. Progressive Web Apps uplift the web’s capabilities.

Anatomy of a Progressive Web App

The architecture of Progressive Web Apps is made of up of two pieces: the app shell and dynamic content.

The app shell is like the native code that gets uploaded to an app store.

The app shell is the HTML, CSS, and JS that provide the structure of the page. It’s not the actual content of the page, just the outer structure. The app shell should be cached. After the initial visit this will lead to an “instant” loading feel and the app will be able to load offline.

Chrome engineer Jeff Posnick described it as: “Think of it like the native code that should be uploaded to an app store. But, you still get the link-ability of the web.”

The dynamic content is what populates the app shell. The app shell with the dynamic content is the complete page. By splitting your app into these two pieces, it can easily work offline.

Addy Osmani and Matt Gaunt wrote an excellent article that explains this architecture in great detail.

Offline

It’s rare to see a web app work offline. It’s even more rare to see one load when there’s no internet connection. Progressive Web Apps can do both.

By using ServiceWorker your app shell is cached for offline use. Even if the network is lost, Progressive Web Apps will load the app shell at the very least.

The web manifest file for the app specifies this in the “start_url” property. This is tell the manifest file that you are guaranteeing that when the app goes offline this app shell will load. It’s ServiceWorker that coordinates the offline magic.

ServiceWorker

ServiceWorker is a network proxy written in JavaScript that intercepts HTTP requests. ServiceWorker is a hard thing to describe, but Jeff Posnick came up with an excellent analogy.

ServiceWorker is an air traffic controller. Think of your web apps requests as planes taking off. ServiceWorker is the air traffic controller that routes the requests. It can load from the network or even off the cache.

To simplify ServiceWorker development the Chrome Team created two tools: sw-precache and sw-toolbox.

The sw-precache tool takes care of caching and maintaining of the resources in the app-shell. The sw-toolbox tool provides the strategies for your dynamic content.

Using them together gives you a library that loads your shell instantly, while giving you fine-grain control over the loading process.

Push Notifications for Engagement

The web excels when it comes to reach. But native is optimal for engagement and daily active use. Owen Campbell-Moore, a Project Manager on Chrome asked “How do we take the reach and combine it with the engagement with push notifications that the devices have?”

Web Push = Reach + Engagement

The answer is Web Push. Web apps can send our devices push notifications even while Chrome isn’t running, through the magic of ServiceWorker.

It wasn’t just the tooling around Progressive Web Apps that got better. Chrome itself got a whole new suite of features.

DevTools got a serious upgrade

Designers spend more time in Chrome than you think. Chrome is now rolling out more features that help with rapid prototyping in Chrome.

Animation Inspector in Chrome.

The Chrome DevTools have a brand new mobile device mode and animation inspector. Download Chrome Canary and give it a spin.

Developers also received a new shiny tool to help with HTTPS.

The new Security panel

Security panel in Chrome.

Progressive Web Apps require HTTPS. It’s 2015, HTTPS is not an upgrade, its a standard. When a page is secure, Chrome signifies it through its “Green Lock”.

An attacker should not be able to read the data that goes between the browser and the server.

Emily Stark terrified us with stories of web security, but then unveiled the Security panel in the Chrome Dev Tools. The Security panel helps developers find and fix problems that prevent Chrome’s “Green Lock” of security.

The main problem when switching to HTTPS is mixed content. If your page contains assets loaded over HTTP (images, scripts, etc…) then your page is only partially secure. This means you won’t get the “Green Lock”

The new Security Panel provides the tools for you to get to green.

Talks to watch

All of them. Seriously, each talk at the Summit was excellent.

But if you’re looking to learn all you can about Progressive Web Apps, I recommend watching these:

1. Progressive Web Apps — Alex Russell & Andreas Bovens
2. Instant App Loads with Service Worker — Jeff Posnick
3. Building Progressive Web Apps with Polymer — Rob Dodson
4. Deploying HTTPS: The Green Lock and Beyond— Emily Stark
5. Intro to RAIL — Paul Irish & Paul Lewis

But really, they all were fantastic.

Go build a Progressive Web App

There’s nothing quite like seeing the “Add to Homescreen” button appearing on your web app. Check out these tutorials and examples to help build your own.

• Code-labs.io tutorial — Build a Progressive Web App with sw-precache.
• Zuperkulblog — A Progressive Web App built with Polymer.
• Airhorner — An offline airhorn that looks and feels like a native app.
• Firebase Hosting — Free SSL. And the Firebase SDK handles intermittent offline connections.

David East is a Developer Advocate at Google working on the Firebase team. He takes full advantage of Google’s free coffee perk. You can find him on Twitter at @_davideast.