I Watched All of the Chrome Dev Summit 2017 Videos So You Don’t Have To

There were few announcements and a lot of PWA evangelism.

Dan Fabulich

Published in

Code Red

14 min readOct 27, 2017

Dan Fabulich is a Principal Engineer at Redfin. (We’re hiring!)

All of the videos from Chrome Dev Summit 2017 are available online. Ten hours of video.

tl;dr: Google wants you to build PWAs, reduce JavaScript file size, use Web Components, and configure autofill. They announced only a handful of features around payments, authentication, Android Trusted Web Activities, Chrome Dev Tools, and the Chrome User Experience Report.

Discuss on Reddit
Discuss on Hacker News

At CDS, you’ll typically see Google doing three things:

Promote web technologies that they want people to use
Announce/re-announce new stuff (often confusingly similar to stuff they already have)
Share practical advice for web developers

But sometimes their “announcements” are actually re-announcements of pre-existing technologies that they’re trying to promote. Sometimes Google advocates web technologies that aren’t practical, or aren’t practical yet, e.g. because they’re brand new in beta, or because they only work in Chrome.

What Google Wants You to Do

Build Progressive Web Apps. Specifically, they want you to use Service Workers to make your app do something useful when you’re offline. This has been a hard sell for Google, because Service Workers don’t work on iOS. Apple finally just started working on it earlier this year; we’ll be lucky if it becomes available in iOS 12.
Significantly reduce the amount of JavaScript websites send down. Google recommends targeting a 5s goal for the “time to interactive” event on low-power, <$100 (“cheap”) Android phones. Web developers in wealthy western nations tend to use iPhones or high-end Android devices with much better performance characteristics. (The iPhone 8 has 8MB of L2 CPU cache; even many high-end Android phones typically have no L2 cache at all.) On cheap phones, Google estimates that you can typically afford only 1MB of minified ungzipped JavaScript, or 150KB gzipped. It’s difficult to convince to most web developers to accept these limits, especially if you don’t anticipate selling a lot of products to “emerging markets” nations. Hitting Google’s recommended target often requires a ground-up rewrite, discarding well-loved JS frameworks.
Use Web Components. (Today, that means Custom Elements and Shadow DOM; they seem to be giving up on HTML Imports). Specifically, they’d like you to use Polymer. The problem is that the Web Component API is really unpleasant to use directly, especially compared to React. That’s really holding Polymer back in the framework marketplace. Other WC-based frameworks like Svelte, Skate, and Stencil abstract away from WCs, treating them as a compilation target. (WCs have another big problem: there’s no good server-side rendering strategy for Shadow DOM, and especially no efficient way to “rehydrate” WCs on the client side from server-rendered non-WC output.) Google also feels that WCs are an important strategy to hit their recommended target; you can save a lot of bytes of JavaScript if you “use the platform” and avoid reinventing it in JS.
Configure your forms to support autofill, especially for login and checkout forms. It’s almost shocking how many popular e-commerce checkout experiences completely ignore autofill, which can be especially important on mobile browsers. In recent years, Chrome has added new autofill features, including the Credential Management API and the Payment Request API, but sites have been slow to adopt them, probably due to poor browser support.

What They Announced

Payments: similar to what they already had, but a bit different

It’s the Google Payment API. After replacing Google Checkout with Google Wallet, and then replacing that with Android Pay, the docs have the audacity to call it “The newest way to pay with Google.” 🙄

The Google Payment API only works in Chrome on Android; it integrates with the “standard” but poorly supported Payment Request API. It’s effectively Android Pay in Android Chrome. Hopefully they’ll expand support to other platforms and other browsers over time.

At the same time, they announced that the Payment Request API is now available on all of Chrome’s platforms, whereas it used to be restricted to Android only.

Authentication: similar to what they already had, but a bit different

They introduced two features, “Automatic Sign In” and “One-tap Sign Up.”

Of course, you’ve been able to sign in/up with Google using “Google Sign-In” for years. (Briefly they called it “Sign in with Google Plus.”) But in this version, it’s an animated toast that appears at the bottom of the screen, offering to let the user sign in with Google.

The new “one-tap” flow is also designed to polyfill the Credential Management API, allowing you to use it on iOS, so that’s nice.

Trusted Web Activities: PWA tabs in Android apps

Trusted Web Activities are a way to launch Chrome Custom Tabs in an Android app without showing the URL bar; it’s designed to make your own website a screen in an Android app, and to make it even easier to package a PWA as an Android app in the Google Play Store.

A bunch of small improvements to Chrome Dev Tools

As with most Dev Tools features, they’re hard to describe; you kinda have to watch the video to see how they work. They demonstrated CSS Grid Layout inspection, “local overrides” (a way to make saved Greasemonkey “user scripts” in Dev Tools), a new realtime Performance Monitor, console log enhancements to filter and group similar events, and more PWA improvements in the Application tab.

They marked the #1 bug in Dev Tools as fixed live on stage, allowing multiple clients to use the Chrome Dev Tools for remote debugging.

Chrome User Experience Report

The Chrome User Experience Report is a BigQuery queryable dataset of real user monitoring performance data for the top 1,000 websites. I find it hard to see who would use it for what, but hopefully somebody will do something cool with it.

The Talks Themselves

The talks this year felt weirdly disjointed. All of the talks were 30 minutes long, regardless of whether that made sense for the topic in question; often it felt like they had two or three speakers share a time slot, even though their respective talks didn’t have that much to do with each other.

Even when there was one speaker, I often had the feeling that the speaker had a laundry list of stuff they had to cover with no particular thematic unity. It’s hard to convey what particular talks were about.

Despite that, I’ll try my best.

Keynote (Ben Galbraith and Dion Almaer): A listicle talk. Service Workers, HTTPS, autofill, authentication, web media APIs, Trusted Web Activities, Web Components, CSS Grid, ES6 + ES2016, WASM, MDN Web Docs, Dev Tools.
The New Bar for Web Experiences (Thao Tran and Chris Wilson): An extension of the keynote, again covering a laundry list of stuff. Talking about using Service Workers as “the bar” is yet another attempt to cajole developers into using a technology that’s been slow to take up.
Integrating with Operating Systems (Owen Campbell-Moore): Owen had a bunch of ideas to cover. New “Add to Home Screen” (A2HS) modal flow; Trusted Web Activities; Firefox for Android and Samsung Internet Browser now support PWAs; Microsoft supports PWAs in the Windows Store. But wait, there’s more: web media APIs; Service Worker’s Background Sync API and Notification API; the Web Share API; the Payment Request API and its evil twin the Google Payments API; the new One-tap Sign Up and Automatic Sign In APIs; and “one more thing,” support for desktop PWAs in Chrome, coming 2018.
Kickstarting Your Journey to Progressive Web Apps (Ewa Gasperowicz): Decide what to improve using analysis tools like Lighthouse, prioritize prerequisites for PWAs (practical advice like optimizing images, using the browser cache, code splitting, and HTTPS), then implement, and re-analyze.
Fast by Default: Modern Loading Best Practices (Addy Osmani, Ilya Grigorik and Bryan McQuade): Another huge list of material to cover. There’s an early slide, screenshot below, with a big list of good suggestions, none of which Addy had time to cover in any detail! He discussed the math leading to a 150KB JS budget. Then, randomly, Ilya and Bryan came up to announce the Chrome User Experience Report. Back to Addy, where he talked about font-display: optional, navigator.connection.effectiveType, and link rel=preload. Addy concluded by talking through the Pinterest and Tinder PWAs as case studies, because this talk, like all the others, was about everything and so it was about nothing in particular.

Workbox: Flexible PWA Libraries (Jeff Posnick): Workbox is a nifty library for automatically generating Service Workers, which is nice because the SW API is brutally hard to work with. It’s built on the old sw-toolbox and sw-precache libraries.
Wordpress + PWAs (Surma and Dan Walmsley): Surma (his name is one word) demo’d a proof of concept PWA built on Wordpress. Dan from Automattic came up to say that their closed-source Jetpack plugin for WP also offers preliminary PWA support.
Progressively Improving E-Commerce (Sam Dutton and Rowan Merewood): A much more coherent talk, full of practical advice, but still fundamentally listy. Show critical content first (the key product photo, not the menu bar), keep your page load stable (pre-declare image sizes), optimize images, use Intersection Observer for scrolling lists, use placeholder images e.g. image-trace-loader. Use link rel=prefetch for predictive loading. Offline client-side search with Luna. Mark up your forms so they’ll autofill.
Building a Modern Media Experience (Francois Beaufort and John Pallett): Call out to the Shaka player, the preload attribute on the <video> tag in contrast with link rel=preload, the media session API for syncing media playback timelines between your phone and your Android Wear watch 🙄, and pausing the video with the visibilitychange event or with Intersection Observers.
The Web for the Entire World (Tal Oppenheimer): A ton of interesting data on internet use, especially in India. Both China and India use the internet more than the United States. 33% of smartphone users in India run out of storage space every day. 24% are on phones under $100. At least 53% of India’s users will be on 2G networks for the next three years. There are 28x as many debit cards as credit cards. Also a couple of practical tips: in Chrome 63, there’s a navigator.deviceMemory API and a client hint header to know how much memory the device has, and navigator.connection.effectiveType to estimate network quality. (And, of course, nobody at Google can give a half-hour talk about India without advocating for Service Workers.)
Modern Tooling, Testing, and Automation (Eric Bidelman and Paul Irish): As with most Dev Tools features, they’re hard to describe; you kinda have to watch the video to see how they work. Paul demonstrated CSS Grid Layout inspection, “local overrides” (a way to make saved Greasemonkey “user scripts” in Dev Tools), a new realtime Performance Monitor, console log enhancements to filter and group similar events, and more PWA improvements in the Application tab. But then, halfway through the talk, Eric came on to talk through Chrome Puppeteer, a nice easy-to-use Node API for automating Chrome. Then they switched back to Paul, who closed out the talk by marking the #1 bug in Dev Tools as fixed, live on stage, allowing multiple remote clients to debug Chrome.
The Future of Loading on the Web (Sam Saccone): A forward-looking view of what features may come to the web platform soon, and how they’ll change loading on the web. As a result, there are basically no practical takeaways that you can use today. 😞 Sam mentioned that V8 will begin automatically caching parsed and compiled JS, so granular caching will become more important than ever. He called out dynamic imports with async import('./blah.js') which could be combined with network.connection.effectiveType or .rtt to decide whether to download big bundles or smaller granules. Next up, H2 Cache Digests, a way to prevent overpushing during H2 Push. Then, explicit priorities for scripts and images; async images which can defer decoding (inexplicably, they still decode on the main thread); and DOMChangeList, an API that would allow Web Workers to generate a list of DOM changes which the main thread can then commit. The DOMChangeList could be shared via a SharedArrayBuffer, allowing the Web Worker to share memory with the main thread directly.
V8 Today and in the Future (Thomas Nattestad): V8 got faster again. 🎉 Also, the new ES6 & ES2016 features are fully supported at top speed, so consider using babel-preset-env so you can automatically use modern JS features on the latest Chrome.
Real World WebAssembly (Alex Danilo and Deepti Gandluri): WASM is supported on all modern browsers now, so you can actually use it. They showed some cool demos, including an image decoder and an IDE in WASM. Coming soon: threads, improved debugging, fixed width SIMD, zero-cost exception handling (currently C++ exceptions are simulated in JS 👎), and garbage collection.
End-to-End Polymer Apps and the Modern Web Platform (Taylor Savage): Polymer advocates always seem so bitter, and this talk was no exception, starting with some snarky remarks about the “javascript-industrial complex” in favor of short-term thinking instead of long-view ecosystem health. (Do they really think a conspiracy theory explains why nobody likes Polymer or working directly with Web Components??) Moving on, Taylor mentioned Polymer 3, which switches from bower to npm, and switches from HTML Imports to ES6 Modules. (Google seems to be abandoning HTML imports, since Safari, Firefox, and Edge don’t plan to support them.) He briefly appeared to acknowledge the developer-experience problems with Polymer, then talked about four features, none of which seem to directly address Polymer’s developer-experience problems. He says that there will be tools to help you stay under Google’s arbitrary 150KB limit (50KB per route), but didn’t say what these features will be. He suggested that Web Components will be useful for “app-level components” (no details), promoted Redux for Polymer, and linked toprpl-server-node. None of this meaningfully addresses the developer-experience problems with Polymer, as far as I can tell, leading me to deeply wonder if Taylor or the Polymer team really understands their problems. Until …
lit-HTML (Justin Fagnani): A new framework from the Polymer team with absolutely no Polymer in it. It feels very React-ish, including an JSX-alike based on HTML Templates where UI is a pure function of state. But the key is: it doesn’t use Web Components. You can wrap lit-HTML in WCs, just like you can wrap React components up as WCs, but you gain nothing from it. It’s a interesting approach, but it’s still very new, not 1.0 yet, and it’ll be in direct competition with Polymer, Angular, Svelte, Skate, and Stencil. Wait and see, I guess.
Creating Media Without an App (Mat Scales, Jennifer Lin, Peter Shin): Jennifer and Peter from Instagram walked through their approach to PWA. They used Workbox and Shaka player, and they had to do a ton of WebGL perf enhancements to get it to perform acceptably. They also use Background Sync API for offline image upload. (Demo fail.) Then the Instagram team retreated and Mat on the Chrome team came back to remind us of the Media Session API, Image Capture API, Media Recorder API, and the idea of using WASM for image transformation.
The Future of Immersive Experiences on the Web with VR and AR (Josh Carpenter and Brandon Jones): WebVR isn’t even rolled out yet, but it’s getting a “2.0” in quotes because 1.0 was only an experimental origin trial. WebVR 2 will make “magic window” UIs in non-headset devices easier, use a more prescriptive rendering approach for easier optimization, wrap the input API to make it easier to use, and require a splash screen so the user never stares into darkness while the WebVR experience loads. They’re also shipping ARCore libraries for Android, to compete with Apple’s ARKit library.

Q&A Panels

The panels were a lot better than most of the talks, in my opinion, and I say that not just because they took a bunch of my questions. 😁

Leadership Panel

Moderator: Chris Wilson
Panelists: Darin Fisher, Parisa Tabriz, Grace Kloba, Thao Tran, Tal Oppenheimer, Matt McNulty, Alex Komoroske, and Alex Russell

AMP vs PWA? Darin: Goal is a fast web.
Why no PWA summit this year? Chris: It’s not just about PWAs.
Do you support a JavaScript Binary AST? Alex R: There are other approaches, including Service Workers caching parsed & compiled output. Binary AST has long term consequences, not all of which we think we understand entirely.
“Add to Homescreen” on Desktop? Alex K: You can kinda do it today, but it’s buried. Owen showed a screenshot of something new happening here; expect it in the coming months. (Look for it in Chrome flags.)
Should I transpile ES6 or write it directly? Alex R: Who are your users? If your users support it directly, use it. Otherwise, transpile.
What was good and bad about the WebKit/Blink fork? Alex K: We have a great community around Blink now. Our goal is to move the web as fast as we can. Alex R: We value competition. We all have to catch up when another team does something cool. Darin: You might think there would be more incompatibilities, but we were already effectively forked with a ton of ifdef sections all over the code. Alex K: One thing that can be worse is compatibility edge cases between browsers. We have a “predictability” team who works on web tests, and folks who land changes in other open-source browsers.
Should several teams work on rendering engines, or one big browser? Alex R: As a web dev, I want one browser. But competition means that one big browser can’t/won’t stagnate. Alex K: The browser wars are way better now; we’re all doing a great job of cooperating with each other. Grace: There’s inherent value in diversity in approaching these technical problems.
What’s up with Google’s identity crisis around PWAs and Android Instant Apps? Parisa: Again, we value competition, even internally within Google. The world is better off with more options.
Why highlight AMP in search results and not PWAs? We’re not the search team.
What’s up with Chrome-only sites? We don’t like that; we reach out internally and try to get them to stop.
How much storage can a web site respectfully store offline? Alex R: We’ve greatly increased the quotas here, up to a percentage of the user’s disk.
Why can’t you install PWAs in GPS? Darin: Well, you kinda can. And now we have Trusted Web Activities which will make it even easier.
What will you be most proud of in the next 10 years? Alex R: Helping the web survive the next change in form factor, after mobile. Alex K: Healthy competition. Matt: Kept the user first. Tal: We built a web for all users. Thao: Getting to a world where I build once and it works everywhere. Grace: Handling the next platform. Parisa: Growth of HTTPS, and instituting a secure, auditable PKI. Darin: Working on Chrome for 21 years.

Frameworks Panel

Moderator: Addy Osmani
Panelists: Andrew Clark (React), Jason Miller (Preact), Steve Orvell (Polymer), Rob Wormald (Angular), Tracy Lee (RxJS), Chad Hietala (Glimmer), Sean Larkin (Webpack), Malte Ubl (AMP), and Alex Russell

What new browser feature would most benefit your frameworks? Jason: DOMChangeList. Rob: +1 DOMChangeList, and Observables. Tracy: +1 Observables. Malte: Better Dev Tools for Web Workers. Real weak references. Steve: Allowing WCs to do more stuff native elements can’t do. Andrew: Making any element async. Async append, similar to DOMChangeList.
What criteria should we use to choose a framework? Alex: How much headroom does it take in terms of bytes?
How do you interop? Tracy: It would be nice, but. Sean: Vue will blaze trail. Preact can import a Vue component today. Jason: We can all agree to compile to Web Components. Steve: WCs are designed to do interop. Rob: It would be great if Angular components spit out WCs. Andrew: WCs are cool, but we on the React team aren’t convinced that we should replace React components with WCs. People say you can get rid of vdom, but we use it not just for encapsulation but for memoization, computing changes, for scheduling. Alex: WC and VDOM are orthogonal. SkateJS is using VDOM in custom elements.
How will WebAssembly impact frameworks? Chad: It compliments JS. Jason: We’ll use it as a polyfill for performance-critical sections.
How can we improve diversity in OSS? Tracy: We do a women tech makers initiative. We have a good number of junior women developers; we have to find a way to make them senior. Sean: We’re doing outreach efforts like Webpack Africa.

Discuss on Reddit
Discuss on Hacker News

P.S. Redfin is hiring.