Highlights from Chrome Dev Summit 2016

A couple of weeks ago I was lucky enough to be able to attend the Chrome Dev Summit in San Francisco. It was a really great experience to be able to see, in person, a lot of the people working on the APIs I use everyday, as well as to see how other developers are creating complex modern web applications.

I would urge you to watch all the videos yourself (Chrome Dev Summit 2016 Playlist), but here are the top 5 things I found the most interesting/exciting.

Web Payments #

Zach Koch (Product Manager, Chrome) spoke on the first day about Web Payments, and how to use the new Payment Request API.

The Payment Request API is a new web API, still in working draft, that is intended to eliminate checkout forms. It aims to provide a standardised and consistent method of making payments on the web for users, by moving the handling of retrieving payment information to the browser, instead of individual checkout forms on each website.

Making a new payment request is as simple as writing the following -

new PaymentRequest(
  methodData, // required payment method data
  details,    // required information about transaction
  options     // optional parameter for things like shipping, etc.
);

This will trigger the browser UI for collecting payment information. If the user has used it before, they will have already filled information about their credit card and shipping address, so checking out can be as simple as one click. Then, the browser passes the response back to the site in a structured format. Here’s a demo of how it could work -

I find this new API really exciting because it's great for everyone. Users get a more seamless checkout process, and us as developers don't have to deal with creating tedious and complex checkout forms.

The Importance of Testing on Real Devices #

Alex Russell (Software Engineer, Chrome) gave a presentation on Progressive Performance, in which he spoke about the best practices for building truly performant websites today.

His talk was a real eye-opener about how mobile devices perform compared to desktops. An example he gave was the 2015 Google I/O site, which was a Progressive Web App built with Polymer. Using the mobile emulator on Chrome things were fast, with total JS time at less than 600ms and interactive content at about 4s. However, the same site on the same WiFi network loading on a Nexus 5 was significantly slower, with total JS time at about 4s and interactive content at about 7s!

“Your Laptop is a Filthy Liar”

The reason for this is that, no matter how much emulators may try to mimic real devices, they aren't running the same actual hardware, so they will never be actually accurate.

Alex's solution to this is to test your sites on real devices, particularly mid-range circa 2014 devices. This will give you a more realistic representation of what your website is actually performing like for a good portion of your users.

Using Progressive Web Apps with Accelerated Mobile Pages #

Paul Bakaus (Developer Advocate, Google) gave a talk titled, From AMP to PWA - The Best of Both Worlds. In this talk, he spoke about how to use Accelerated Mobile Pages with Progressive Web Apps to create the ultimate performance experience.

In the development environment today where there are so many different frameworks and platforms to choose from, it often seems like you have to make a choice and only use one. But different frameworks have their advantages and disadvantages. AMP, for example, is great for discovery and has a lightening-fast loading time, even on first visit. However, it only allows serving of static content, no user scripts allowed. PWA, on the other hand, have very advanced features and dynamic content, but may not be as easily embedded or have as great discovery in search.

AMP + PWA = PWAMP

In his talk, Paul showed how you can leverage both platforms by using AMP as a data format, a technique he called "AMP down". On first visit, users are served the super fast AMP page, and the Service Worker is installed in the background (Using <amp-install-serviceworker>). On subsequent pages, they are diverted to the PWA, which now loads as fast as if it would on a second visit!

Progressive Web Apps != Single Page Apps #

As is to be expected, Jake Archibald (Developer Advocate, Chrome) spoke about the Service Worker API in his talk, Future App Model: Advanced Service Worker.

In his talk, he challenged the notion that Progressive Web Apps need to be Single Page Apps. Although Single Page Apps been popular because of client-side frameworks and the advent of the App Shell Model, he demonstrated that we can get even faster page loads with server-side renderings by taking advantage of Streams.

Streaming is a behaviour that happens natively on the web. As you may have noticed with regular server-rendered sites, the page content loads progressively. This is because the browser doesn't wait for everything to be received before it starts acting on it. This is behaviour is that is soon coming to the Fetch API. With Streams, we will be able to read the response from a fetch request as it is coming in, and handle how we display the information progressively.

Navigation Transitions #

In Jake Archibald's talk, Future App Model: Advanced Service Worker, he spoke about a lot of speculative features that may be added to the Service Worker API.

My favourite (and the most speculative) was an API for handling navigation transitions. Currently, in order for us to have fancy transitions between pages the way native mobile applications do, we have to use the Single Page Application model. The goal of this API is to give us control over transitions between pages even when the page is server rendered. For example, we should be able to achieve this in the Progressive Web App -

Taken from Slides, "Future App Model"

The way the API would work will be by introducing a new event, navigate, that we can listen for in the window. For example, a simple cross-fade transition could be written like this -

// Listen for a new "navigate" event
window.addEventListener('navigate', event => {
  // Keep the current document alive until this Promise is resolved
  event.transitionUntil(

    // Get the new window
    event.newWindow.then(newWin => {
      if (!newWin) return;

      // assuming newWin.document.interactive means DOM ready
      return newWin.document.interactive.then(() => {
        return newWin.document.documentElement.animate([
          {opacity: 0}, {opacity: 1}
        ], 1000).finished;
      });
    })
  );
});

// Example from https://github.com/jakearchibald/navigation-transitions

There were lots more interesting content at the summit, for example the Lyft team sharing how they created a 40KB G-Zipped Progressive Web App 😱!If you're interested, you can watch the recordings here.