Welcome to this summary of Jason Savage’s Polymer and Progressive Web Apps talk at Google I/O 2016.

If you are new to Polymer, you might also be interested in Kevin Schaaf’s Thinking in Polymer talk.

Taylor Savage is the Polymer Project’s Product Manager.

He says the sole goal of Polymer is to build tools and libraries using the latest web platform features, for us developers so that we can build next generation web apps.

These are also known as Progressive Web Apps.

Or, the 2 second pitch is:

“Use the platform to deliver great user experiences”.

Taylor reminds us of HTML tags and their limitations. He says JavaScript has gotten much more powerful over the last 20 years and has become an escape hatch for developing app-like experiences.

He says the mobile web has been a major change, which is incredibly powerful and has incredible reach.

However there are limitations with data connections and device hardware. And the next billion people coming online typically have the worst connections and the worst hardware.

This is a new challenge for the mobile web. So far the solution has been more and more and more JavaScript, but the Polymer team believes in a better solution.

Less JavaScript

Use the Platform

 

The browser has the vast majority of what the users need to run their applications.

The team believes the platform can be used to build lower overhead and higher quality applications.

The are two parts to this: Using Web Components and Building Web Components.

Using Web Components

The hardest part of building a mobile web app is knowing where to start. Usually it starts with choosing a JavaScript framework.

The problem is after you choose one, almost every line of code you write will be tied to that framework decision that you made.

There are a couple of big costs involved in using a framework:

1. The cost your users pay as they download the framework before they can run any of your code. They both in terms of their time and literally in the form of paying more money for their mobile data plan.
2. The cost that us developers pay. All components we write are tied to our framework choice. Making the functionality available in a different framework requires a rewrite.

Taylor introduces Web Components as a new W3C standard (this isn’t entirely true, but it should become a recommendation soon).

All browsers need to speak HTML as it’s the lowest level visual primitive of the web. Each new component is a new HTML tag, a new custom element.

Taylor says the first draft of Web Components came out 12th May 2012. It is an umbrella term for the following:

• Template Element
• HTML Imports
• Custom Elements
• Shadow DOM

As with all cutting edge web features, polyfills are required for older browsers that don’t support them. Only the very latest browsers currently support the v1 Web Components spec. These features are already being used by major companies:

• Github uses custom elements for all of its time stamps and emoji across it’s site.
• Twitter is using Shadow DOM

For thousands of ready made custom elements see customelements.io

Taylor says Web Components used to be on the bleeding edge of web development, but are now just on the leading edge.

The Polymer library makes it easier to use the 4 Web Components specs together to create our own web components.

The early version of Polymer was slow, but version 1.0 was completely rewritten to make it construct elements 3 to 4 times faster. Taylor says the latest version is another 25% faster on Chrome.

In Rob Eisenberg’s Choosing a JavaScript framework talk, Polymer comes out well and I was surprised to see that it’s repaint performance on Chrome is faster than both Angular 1.x and React JS.

Google have already used Polymer for the following products:

• Chrome
• Translate
• Play Music
• YouTube
• Gaming
• Fi
• Google I/O Web app

He says Polymer is already being served in production to over a billion users of Google products, and discusses two other global companies using Polymer: Net-A-Porter and BBVA.

Next he says developers want more guidance than just to build components out of components out of components etc.

Again Google’s advice is to use the platform.

As I watched this part, it finally dawned on me that use of Polymer leads to increased use of Google Chrome. As Google’s Chrome team tends to implement the latest web platform features first, users of products built with Polymer run best on Chrome.

I have found that Polymer repaints much quicker on Chrome than on Edge. Angular 1 performs better than Polymer there, but Polymer still renders faster than React (DB monster tests).

Polymer App Toolbox

This is a set of components and tools that make it easier to build Progressive Web Apps:

Layout

There are no HTML tags for a responsive drawer, but this is a common UI control in mobile apps today. The Polymer team built app-layout elements for this.

Taylor shows a demo of some of these elements and the user experience that it creates on a mobile phone.

See the Test Drive Demo on your mobile device.

Routing

You can use any router with Polymer, but the Polymer team wanted to build a router that worked like Web Components: modular and composable. This is the app-route element.

Localization

Again you can use any localization solution you want, but the Polymer team has built the app-localize-behavior element for this. This uses the JavaScript Intl global object. This is part of the ECMAScript Internationalization API and is well supported in modern browsers.

This can be used to translate strings, currencies, numbers, dates, plurals and genders.

Storage

We might want to store data either on the cloud or device? There are a million ways to do it, but the Polymer team have made it easy with app-storage.

It’s an interface allowing us to create our own web component to connect data from any service. This is serviced as a property on the DOM Node.

As an example we see a TODO type app that writes the notes via a REST API. We won’t be able to save if the user is offline. In that situation we can use Indexed DB.

There is an app-indexeddb-mirror interface for this.

If you don’t want to build your own REST API to manage the data, preferring to use a database as a service in the cloud, you can use app-storage with Polymerfire.

The Modern Web Platform

Here are the three main elements:

• Web Components
• HTTP/2 Server Push
• Service Worker

Taylor breifly explains HTTP/2 Server Push.

If you are a Pluralsight subscriber I highly recommend Hadi Hariri’s HTTP/2 Fundamentals course to get a full understanding of this.

If not, then there are plenty of other resources available online. See my Performance page for more details.

Taylor discusses the pattern:

• Push components for initial route
• Render the initial route asap
• Pre-cache the components for remaining routes
• Lazy-load & create next routes on demand

This is known as the PRPL pattern, and it’s not specific to Polymer. Rather it’s a technique for high performance modern web apps, such as Progressive Web Apps.

The benefits of this pattern are:

• Minimal payload
• Minimal overhead
• Optimal user experience

CLI

The goal of the Polymer Command Line Tool is to stay focused and simple.

Available commands are similar to how npm works:

• polymer init – initialize your application
• polymer serve – locally serves your application or component
• polymer lint – lints your code
• polymer build – build your app. allows your to specify main entry point

As well as the ability to use the PRPL pattern, Polymer generates a bundled version optimized for HTTP 1.1.

Didn’t we just build another stack?

No, it’s not a stack, just a set of loosely coupled, interoperable web components.

The Shop App

Shop App

Having seen all of this, I am excited with everything Polymer has to offer and am going to try it out right away!

There will also be a Polymer Summit in London this October!

Further Reading

Polymer Toolbox

The Polyglot Developer – Using Polymer with Apache Cordova

Polymer and React.js – Clash of the Titans

Practical lessons from a year of building web components – Google I/O 2016