Skip to main content

My Fairly Complete Notes from Chrome Dev Summit 2017

Here are my notes from Chrome Dev Summit 2017:

Here's the schedule.

Here are the videos.


Ben Galbraith and Dion Almaer, Director, Chrome Web Platform and Director, Developer Relations

@bgalbs and @dalmaer

This was the best talk of the whole conference. They covered a lot of new stuff in a very short amount of time. This one talk is the talk that's the most worth watching.

They plugged PWAs (Progressive Web Apps).

Lots of browsers support Service Workers. It's still in development for Edge and WebKit, though.

Workbox is a library they built for working with Service Workers. It's used by 70% of the sites using Service Workers.

They plugged

64% of traffic is transmitted over HTTPS on Chrome on Android.

They're going to start marking any form that isn't submitted over HTTPS as not secure.

Use autofill completion hints to help out Chrome with autofill.

They plugged PaymentRequest. It's a payment UI that is built into Chrome itself. It cuts down the transaction time by 75%. All the big browsers are going to support it.

There's also a Google Payments API, but that's something different.

New API: One tap sign up:

Chrome can synchronize your media between phone and watch.

There's an updated image picker UI in Chrome.

You can control the media hardware via MediaStream.

Shaka is a new video player. Instagram uses it on their site.

You can use Custom Tabs instead of a webview.

Trusted Web Activity is a new API they're launching today. Run full screen. It's the best of native and web in one experience. Hmm, I can't wrap my head around it yet, but it seems really important.

They plugged Web Components and Polymer. Safari recently added support for Web Components.

They plugged AMP.

The latest YouTube uses Web Components and Polymer.

They plugged CSS Grid Layout. See

The browsers have pretty good coverage of ES2015.

They plugged async, await, and import().

They shipped a new version of V8 with a very different architecture that's a lot faster. It's 22% faster on Speedometer. It's 5% faster on the top 25 websites.

They plugged WebAssembly (WASM). It's supported by Chrome, Firefox, and Safari. Edge shipped support as of today!

Unity and Unreal Engine are both going to support (or already support) WASM.

Mozilla, Microsoft, and Google are working together to put all their web docs on

They're fixing interop bugs using web-platform-tests.

They plugged Chrome Dev Tools and Lighthouse.

Puppeteer is a project for controlling headless Chrome.

They plugged WebPagtest.

They're announcing something new: Chrome User Experience Report. It's a bunch of data about users using big sites across the world. It's being made available via BigQuery.

A New Bar for Modern Web Experiences

Thao Tran and Chris Wilson, Strategic Partner Development Manager, Developer Advocate

@thaotran and @cwilso

Chris Wilson started with Mosaic.

"It's time to radically improve your user experience."

PWAs are just a higher bar for user experience.

The new bar (FIRE):

  • Fast
  • Integrated
  • Reliable
  • Engaging


60% of mobile connections world-wide are on 2G.

Focus on fast. uses an app shell. They get a skeleton up on the screen in 400ms on a mobile device. They're fully loaded in 2s.

25 million domains use AMP.


You can now control your web-based media even on the lock screen using some new API.

They plugged push notifications. Push notifications are a good approach for responding to users who put in support requests.

With the Identity API, once you sign in on one device, you're signed in on the others too.

The PaymentRequest API lets users check out 80% faster using a browser-native UI.

90% of permissions prompts are dismissed or ignored.

In some upcoming version of Chrome, if a user dismisses a permissions request 3 times in a row, it won't pop up again for a week. They're also going to make them modal dialogs.

It's important to only ask for permission when it's in context.

When you block a permission, that's permanent.


"Reliability means never showing the Downasaur." — Chris Wilson

Uber built a PWA,, pronounced "moober". They're PWA's JavaScript is only 50kb.


The previous three things lead to engaging apps.

They talked about gracefully handling being temporarily offline. This is really important.

Integrating web apps with browsers and operating systems

Owen Campbell-Moore, Product Manager, Chrome

@owencm PM for PWAs.

"Progressive Web Apps should provide an immersive, integrated experience on all platforms and OSs."

He talked about history, including lack of offline support and notifications, Mobile Chrome Apps, Cordova, etc.

When he joined Google, Chrome was focused on offline, notifications, and installability.

The "Improved add to home screen" feature is now launched to 100% of users. It integrates PWAs deeply into Android.

What about integrating web into Android apps? With Trusted Web activities, Android apps can include app-like content served from the Web. It's powered by the same runtime that powers PWAs.

The Android app and the web content have to be written via the same company (i.e. there is some sort of check to prevent you from embedding some other site's web content into your app).

This is just a new pattern for integrating web content into your Android app.

Native app install banners promote your app from your site.

@andreasbovens from Mozilla.

Firefox is adding "Add to home screen" in Firefox for Android.

Samsung Internet browser has been mentioned numerous times.

Microsoft is listing PWAs in the Windows store.

They're rolling out a new image upload UI:

<input type="file" accept="image/*" multiple></input>

They have an Image Capture API as well. It's called ImageCapture.

There's a Background Sync API. This guarantees "uploads can upload successfully" by temporarily storing things if the user goes offline.

You can now use images and buttons in your notifications.

The Web Share API integrates with the native Android share system.

Payment Request API is now on all platforms.

They also have Pay with Google using the Payment Request API that has lots of supported payment methods.

He plugged the Identity (Credential Management) API.

He talked about "One-Tap Sign-In" in every browser. It's just a library. They're also announcing "One-Tap Sign-Up". Early numbers show that it can increase sign ups by 200-300%. See

With the Media Session API, you can integrate with the user's OS and devices.

They're adding PWA support to desktop Chrome.

Service Worker support is coming soon to Safari.

Kickstart your PWA journey

Ewa Gasperowicz, Developer Programs Engineer, Chrome


This talk is aimed at the really big web apps that are shy about attempting a PWA migration.

The process:

  • Coffee
  • Analyze
  • Prioritize
  • Choose tools
  • Implement
  • Evaluate


Lighthouse is quite helpful.

You can download a report in order to compare between different versions. You can use to view the report.

She also mentioned Chrome Dev Tools, PageSpeed Insights, WebPagetest.


You can pick-and-choose what parts of a PWA you want to implement:

  • PWA ready
  • Performance
  • Service Workers and offline
  • Push notifications
  • Add to home screen
  • Credentials
  • Payments

Don't try to do them all at the same time. Prioritize based on what's the most important for your business.

There is lots of low-hanging fruit you can tackle before tackling the PWA stuff.

Small changes, big improvements:

  • Optimize images
  • Remove unnecessary code
  • Leverage browser caching
  • Avoid blocking code
  • Divide big, monolithic JavaScript

If you have a hero image, provide different sizes using media queries.

Don't embed YouTube videos using their JavaScript API. Use their iframe API.

Remove the full lodash lib in favor of the core.


You need to use HTTPS in order to build a PWA.

UX is the core of PWA.

Workbox can really help with building a PWA.

Don't block transitions because of the network. You can use skeleton screens instead.

Prevent content jumping (i.e. "unstable load"). Ensure a stable load instead. Specify the size of images and dynamic elements.

Cache the right things at the right time.

Prioritize caching images by function:

  • Navigation and action
  • Branding and priority
  • Decorative
  • Informative

For navigation images, you can just cache them inline using SVG.

For branding and priority, just precache them.

For decorative images, cache them at runtime.

For informative images, look at the image's alt tag, and generate the image on the fly if you can't get the original image.

Avoid scrolling glitches.

Scroll quickly with virtualized lists.

Don't ask for permissions on page load. The user won't have any context yet. Ask for permissions in context. Tell them why you're about to ask for the permission.


Compare your earlier snapshots with the app's current behavior.

"Lighthouse at 100%! I'm done!" — said no one ever.

PWA is a mental model for delivering delightful UX:

  • Fast, integrated, reliable, engaging
  • PWA checklist
  • Lighthouse

Make it an iterative process.

Mobile Changes Everything

Addy Osmani, Ilya Grigorik and Bryan McQuade, Developer Programs Engineer, Chrome


Evolving RAIL (Response, Animation, Idle, Load)

User happiness metrics:

  • First paint
  • First contentful paint
  • First meaninful paint
  • Time to interactive

"Networks, CPUs, and disks all hate you. On the client, you pay for what you send in ways you can't easily see." — Alex Russell

There's a huge difference between how fast an iPhone 8 can parse JavaScript vs. how fast average phones can do it.

PRPL pattern: use aggressive code splitting.

Chrome has a memory cache in addition to the HTTP cache.

"Everyone is responsible for performance." Performance budgets can help.

The Moto G4 is their goto "average phone".


  • Dev on an average phone.
  • Keep JS parse/eval low.
  • Have a performance budget.

5 seconds for first load, 2 seconds for reload.

Something new:

The top 50 sites only use 40% of the JavaScript they load upfront.

The P90 of sites send 5.4MB of content.

At P90, sites take 35s before they're fully interactive.

New: Chrome User Experience Report: real world performance as experienced by Chrome users. It's a public dataset on Google BigQuery. See

Be careful: a small site only used by users with fast machines via fast networks will look better than a large service used by a wide distribution of users.

Use font-display: optional: if my web fonts can't load quickly, don't load them at all.

There's also navigation.connection.type (e.g. 'wifi') and navigator.connection.effectiveType (e.g. '2G').

Today, you still need to bundle for production.

"PWAs are the new normal."

Two new PWAs: Pinterest and tinder.

It used to take 23s for Pinterest to get interactive. Now, it's 6.5s.

Their JS bundles went from 620kb to 100kb.

Core engagement is up 60%.


  • Vendor: React, Redux, React Router, etc.
  • Entry
  • Async chunks

Webpack Bundle Analyzer is really important.

They moved to Service Workers more incrementally.

tinder went from 7s to 6s for time to interactive. It wasn't that huge of a win.

Code splitting is important.

Use core-js + babel-preset-env to drop unused polyfills.

Use lodash-webpack-plugin to reduce bundle size.

They're using the ModuleConcatenationPlugin.

mom = measure, optimize, monitor

Workbox: Flexible PWA Libraries

Jeff Posnick, Developer Programs Engineer, Chrome


Service workers sit between your web app and your network, and they can intercept those requests.

You can use a "network-only" strategy to just fetch stuff from the network.

The next approach is service worker + caching. It uses fetch and the Cache Storage API.

Service Workers offer great power, but with that power comes great complexity.

Workbox = build tools + runtime libraries

Workbox allows you to trade complexity for flexibility.

There's a "staleWhileRevalidate" strategy.

A service worker, properly configured, makes your web app fast and reliable.

You can start small and iterate.

Pinterest uses Workbox. They were focused on a fast, reliable experience for logged in users.

They use it for precaching. Critical assets are served cache-first. They have automatic cache cleanup and updates.

There's a precache manifest.

With service workers, you can now cache HTML so that navigation requests bypass the network.

workbox-cli can generate a service worker every time you do a build.

Treat different images differently. Some images should be pre-cached and always available.

window.caches is available to the webpage itself in addition to the service worker.

They're working on a workbox-webpack-plugin. It should be really easy.

Leadership Panel

Chris Wilson, Darin Fisher, Parisa Tabriz, Grace Kloba, Thao Tran, Tal Oppenheimer, Matthew McNulty, Alex Komoroske, Alex Russell, VPs and Directors, Chrome

I missed the first few minutes. Most of it wasn't that noteworthy.

Chrome will allow an app to store a lot more data if the user uses the app a lot.

WordPress + PWAs = Love

Surma and Dan Walmsley, Developer Advocate, Chrome and Engineer, Automatic


PWA = UX++ (i.e. Progressive Web apps make the user experience much better)

WordPress has a 60% market share of CMSs.

28% of websites are built using WordPress.

@danwalmsley from Automattic

WordPress's mission is to democratize publishing.

The Gutenberg Editor is coming out soon. It allows really rich web sites.

Jetpack is the plugin that powers

They experimented with a PWA in Jetpack. They got a 10-15X improvement. DOMContentLoaded went from 15.5s to 0.78s.

Back to @DasSurma.

They do all their development on a Moto G4.

PWAs are not an all-or-nothing thing. Pick and choose what works best for you.

TTFCP = time to first contentful paint

Getting TTFCP < 1s on 3G is quite ambitious, but it's doable. He put everything above the fold in the index.html. It's not perfectly styled, but there's content that's readable.

He started with an empty WordPress theme and added things incrementally.

SSR is crucial for TTFCP.

Separate critical styles (basic colors and space allocations) vs. lazy styles.

In dev, no bundling, no transpiling, native ES6 module loading. In prod, transpile to SystemJS.

Can we actually stop bundling? No. See

You can use <script type="module"> for performance reasons. If the browser supports that, then the browser understands ES6, etc.

"Whatever smart thing you think you did, game developers did it 10 years ago."

Using pubsub was an important part of his architecture.

Nobody has ES6 module support for service workers. This means using globals for shared workers.

Your PWA doesn't need to be very small. It's just your initial load that has to be small.

He used the "stale while revalidate" strategy. Update the cache in the background. Make sure your etags work correctly.

If there is something stale, ask the user to reload.

Progressively improving e-commerce

Sam Dutton and Rowan Merewood, Developer Advocates, Chrome

@rowan_m and @sw12

Be mobile first. There are some companies that are mobile only.

Some mobile users don't have a good smart phones. They have flip phones with some Firefox browser.

66% of purchases on mobile are on the web (rather than apps).

Unless you're one of your customer's favorite stores, you're unlikely to get your app onto their phone.

There are 66% fewer conversions on mobile devices. That's a problem.

It's hard to type on a mobile device.

People spend more time online using mobile devices than desktop devices, but much more money is made from desktop devices.

If you focus too much on performance metrics instead of business metrics, you might be hurting the business.

A lot of people use a mix of devices. Hence, it makes sense to make it really seamless to move between devices. People even shop online before going to a real store.

Technical metrics are an imperfect tool to measure progress towards a business goal.

Show critical content first.

Showing the brand and icon first doesn't really help.

Don't cause the page to jump with late loading content. Everything necessary for the layout of the page should be in the first request.

Mandating a static layout is a really useful trick that can be learned from AMP.

AMP has been adding different things to enable e-commerce.

Overstock added AMP for their category pages. This led to an 8.3% jump in conversion from these pages.

Image optimization is perhaps the biggest thing that most e-commerce sites can do.

Using the wrong format is really bad. You can save 90% of the size by switching from a .png to a .jpg in some cases. Don't use a larger image than necessary.

Smaller images are also faster to decode.

Lazy loading images is also helpful, but there's the risk of adding page jank.

You can use the IntersectionObserver API to load the image when it's within 100px of the viewport.

You have to automate your image production: ImageOptim, MozJPEG, Imageflow, Thumbor, etc.

Lighthouse is really useful for spotting things that can be optimized.

Search is really important for e-commerce sites, and yet it can still be a lot better among the top sites.

They just suggested that it would be awesome if search worked offline. (/me scratches his head.)

Lunr is like Solr, but works in JavaScript.

The major constraint is the index. The index for 1000 items isn't actually that bad.

There's something called elasticlunr.

56% of US consumers ditch their mobile purchases.

Markup your forms correctly so that Chrome autofills forms correctly! This is a huge win, and it's so easy.

The Payment Request API is awesome, and it works across platforms.

The Credential Management API provides frictionless identity across platforms.

E-commerce resources:

Building a modern media website

Francois Beaufort and John Pallett, Developer Programs Engineer, Chrome

The new media APIs are really neat.

Coming in March 2018 on all platforms:

  • Muted autoplay is always allowed.

  • Sound will be allowed if:

    • The user has interacted with the site (a tap or a click).
    • On desktop, the user has previously show interest in sound on the site.
    • On mobile, the user has added the site to the home screen.

Shaka Player:

  • Custom subtitle rendering
  • Offline protected media playback

You can use the video preload attribute. There's also link preload.

"We are all different—and beautiful, by the way."

You can estimate how much free space is left on the device.

The mediaSession API lets you control the media from the lock screen or your watch.

Rotate to full screen is important. screen.orientation.addEventListener().

You can pause the video when the page is hidden. is a good example. It's targeted at low end users, in the same way that Flipkart is.

A lot of Indian users only have an Internet connection for part of the day (such as at work or when visiting a friend's house or coffee shop).

A guy from Kaltura spoke. They support premium grade content that can be used online or offline.

In India, the network sucks and it's expensive.

Voot built a system where users can download video content when they're on the bus system. They're serving a lot of users, and it's all advertising driven.

Our Favorite Bits of the Web

The two engineers MCing the event talked about their favorite bits of the web throughout the day.

They did an emoji state of the union. There are new emoji in the Unicode spec.

You can use emoji as CSS class selectors, which is actually neater than it sounds.

Variable fonts. (This reminds me of metafont.) This is based on font-variation-settings in CSS.

Intersection observers.

Gyroscope (device orientation).

Web VR. lets you use Web Components for VR.

The web for the entire world

Tal Oppenheimer, Product Manager, Chrome


China has the most Internet users.

The US used to be second, but India surpassed it. India is growing faster than any other country.

Potential new Internet users: #1 India, #2 China.

We don't always build with a global audience in mind.

33% of smartphone users in India run out of storage space every day.

24% of Android devices shipping globally in 2017 H1 are < $100, and often have very little memory.

Reliance Jio is driving down the price for data in India. It finally crossed a threshold in Q4 2017 (2% GDP / capita). Some countries still have very high data costs.

In India and Africa, 75% of people are still on 2G.

Downloads are key to address slow connections, decrease repeat data costs, and support offline.

Online payments are way more important than credit cards in India. There are 28X as many debit cards as credit cards in India. There are 818 million debit cards in India.

More than 20% of users from the rapidly growing countries search in 2 or more languages.

The web helps with a lot of the key issues.

Service Workers are in Firefox, Opera, Chrome, Samsung Internet browser, and UC Browser.


PWAs take less storage space. This really helps in India. A 60 MB Android app can be a 200 KB PWA.

PWAs are a key strategy for reach.

Chrome on Android has something called Data Saver which is a server-side thing to help save data.

There's a Save-Data: On header which is present as a hint to tell the server to save data. Remember to show the users that you've saved them data.


Memory is also severely constrained. Know your memory usage.

There's a device memory header and a device memory JS API.

V8 focuses a lot on decreasing heap memory consumption for devices with <= 1 GB RAM.


Remember: Fast, Integrated, Reliable, Engaging

You can learn about the user's connection speed via the NetworkInformation API. You can also look at downlinkMax, downlink, rtt, and effectiveType.

Use Service Workers to build for intermittent connectivity.

Supporting offline is really important for fast playback.

There are web APIs for media such as background fetch while still maintaining control of the data.


Use the Accept-Language header. Remember, it's not necessarily just one language.

Intl.PluralRules has rules about pluralization.

Modern Tooling, Testing, and Automation

Eric Bidelman and Paul Irish, Engineers, Chrome

@paul_irish, @ebidel

Chrome DevTools

CSS Grid Layout Inspection. He gave a shoutout because Firefox did it first.

Color contrast evaluation.

Local overrides. Think of it as offline storage for your tweaks in DevTools. In Sources, there's an Overrides tab. You can create a folder on disk in that tab. You can even edit the HTML and have it persist across reloads. It'll even survive a hard reload.

"Console >> Performance Monitor tab" has all sorts of live performance metrics.

Console now has a filter sidebar. It breaks things down by file, by severity, etc.

Console even has a group similar. It's a checkbox.

You can now use await fetch(…) in the console.

In Application, there is a section on storage, including cache storage. (There was previously a bug in this before.)

In Application, the Service Worker panel has been cleaned up as well.

A yeart ago, Lighthouse diagnosed 50 different issues. Now it's over a 100. There's new stuff concerning loading performance, SEO + UX, and more. It can flag JavaScript libraries with known security vulnerabilities.

They're going to improve the alignment with PageSpeed Insights and WebPagetest.

Headless Chrome and Puppeteer

You just pass —headless on the command line.

See the article, "Getting Started with Headless Chrome". He documents how to setup Karma.

You can also talk to it from Node. There's a simple npm package called chrome-launcher.

Puppeteer is a node library for using headless Chrome. It uses async/await everywhere. It uses ES6 features. It can still support Node 6. No frills. Zero config. It bundles the latest Chromium.

You can generate screenshots and PDFs.

You can crawl an SPA to generate pre-rendered content.

Pupeteer is in lockstep with Chrome.

You can emulate a device.

You can intercept network requests.

Pupeteer can also control Chrome and not have it be headless.

Opening embedded Developer Tools used to terminate any remote debugging sessions. It was their number one bug in Chrome. It's now fixed! Paul Irish closed it while on stage.

The future of performance on the web: A look into upcoming performance patterns

Sam Saccone, Engineer at Google


The future is bright for performance.

In the last 4 years since forking from WebKit, Chrome has shipped 1000 features.

Web performance breakdown:

  • Network bound
  • Parse/execution bound
  • Render bound

Bundling performance

Bundling has long been the gold standard for perf on the web. However, there are some non-trivial perf downsides.

When you change a single bundled file, all dependent bundles are invalidated.

He talked about route-based code splitting.

He talked about shipping each JS file independently.

<script type="module"> has shipped.

When you unbundle everything, it gets slower. See

In the near future, you will not need a one size fits all solution for all clients. You will be able to understand a client's state before shipping your first byte.

Dynamic imports have shipped.

The Network Information API can give you client connection information. This has shipped. navigator.connection.

We are at a loading inflection point:

  • From client fetch to server push
  • From lazy to proactive asset discovery
  • From inferred to explicit priorities

There's a proposal for cache digest for HTTP2 push. It would enable a client to tell the server what assets are in the local client cache.

Not all assets should be treated with the same priority.

There's a proposal for priority hints.

There's a proposal to add group=critical|late to <img>, <script>, etc.

Async images are at the "intent to ship" stage for Chrome. Right now, images block your script.

Runtime perf

There are new paths to optimize the runtime of your app.

Web Workers allow you to move work off the main thread. This has been shipped for a while.

Web Workers don't have access to the DOM.

There's a proposal to enable the construction of DOM operations. It's called a DOMChangeList.

It's cheap to send ArrayBuffers between the Web Worker and the main thread.

You have to use postMessage to communicate between Web Workers. It's about 10ms per message.

There's a proposal that has shipped in Chrome and a few other browsers for shared array buffers. It's mutable shared memory.

Comlink lets you send a proxy from one Web Worker to the main thread so that the main thread can call methods that are proxied to the Web Worker.

Angular can do the majority of its work from a web worker.

V8 today and in the future

Thomas Nattestad, Product Manager, Chrome


They have a new Twitter account, @V8js.

"Speed up real-world performance for modern JavaScript, and enable developers to build a faster future web." — V8's mission

The phrase "real-world" is key.

Two important static test suites: speedometer and ARES6.

They've gotten 22% faster in speedometer since last year. They're 40% faster since May 2017 on ARES6.

They snapshot the top 25 sites. They've gotten 5% faster.

They're reducing jank with concurrent GC (i.e. by taking garbage collection off the main thread).

Project Orinoco is a mostly parallel and concurrent GC system. There are only small slivers of time needed on the main thread.

They now do 56% less GC on the main thread.

There are a lot of tradeoffs in performance.

V8 Ignition is an interpreter with very fast startup and very low memory usage.

V8 TurboFan is used for peak performance with max optimization.

They removed 130,000 lines of code and replaced it with 2 lines to connect it to the new plumbing.

Write the most idiomatic JavaScript, and V8 will try to make it fast. Don't try to avoid parts of JavaScript for performance reasons. They've made great strides.

The size of ES2015+ code is way bigger when you transpile it using Babel. It basically doubles the size and doubles the time to parse and compile it.

Less idiomatic JavaScript is less optimizable.

Should you still be transpiling with Babel? It depends on who your users are. The V8 team likes Babel. You can actually configure how Babel is transpiling.

He started with Babel's preset es2015.

He switched to babel-preset-env. He configured the browsers he cared about. This results in smaller JavaScript.

You can also have both transpiled and non-transpiled code and pick the right version at runtime. Google for "Deploying es2015 code".

They have a rule: no V8 commit can land if it breaks Node.js.

Node 8.3 is a lot faster because of improvements to V8.


  • Write idiomatic JavaScript
  • Transpile ES2015+ selectively

Real World WebAssembly

Alex Danilo and Deepti Gandluri, Engineers, Chrome

@dptig and @alexanderdanilo

Obviously, it's about speed.

WebAssembly is fast, portable, and secure (mathematically proven).

It works alongside JavaScript.

You can compile C++, Rust, etc. and run it in the browser.

WebSight combines WebAssembly and computer vision.

They pronounce it and write it "Wasm".

He said the average website is 1MB, 80% of which is images.

He mentioned Emscripten.

emcc -s WASM=1 -s EXPORTED_FUNCTIONS="['_jpg_transcode']" -o jpgsquash.js jpgtranscode.c

SCIRRA Construct3 is an in-browser game editor. It contains various libraries wrapped in JS. It combines the best of the Web with the best of native.

They're working on threads. It'll take advantage of shared memory.

They're improving support for debugging. Basic debugging already exists, but they're working on source maps, memory inspection, etc.

They're working on adding fixed-width SIMD vectors.

They're working on zero-cost exception handling.

They're working on GC. This will enable other languages.

Chrome, Firefox, Safari, and Edge (as of last week) all support Wasm.

And it works on mobile too.

Autodesk is releasing Autocad using Wasm.

End-to-End Polymer Apps with the Modern Web Platform

Taylor Savage, Product Manager, Chrome


It takes up to a decade to get something into the web platform.

This is where Web Components and Polymer come in.

The big 5 browsers support all the main, necessary features. 1B+ mobile devices support them.

Vue, Preact, and Angular support them.

9 out of the top 16 global brands are using web components.

Polymer 3.0 is in early access preview.

They're moving from Bower to npm.

They're switching from HTML imports to ES6 modules.

HTML imports never reached consensus.

Some of the browsers still require polyfills.

They're going to build an upgrader to upgrade your elements from Polymer 1 and 2 to 3.

They're trying to take the step from components to apps.

Building Modern Web Apps:

  • Structuring for perf
  • Factoring the UI
  • Managing state
  • Serving for production

Structuring for performance

You have to think about performance earlier, not later.

The only way to get better performance on mobile is to do less.

Focus on the user's experience.

SSR is not enough. If it takes a long time to load the JavaScript, it sucks that you can't click on stuff.

Time to Interactive is an important metric.

Don't make the user wait for anything they didn't ask for. No extra code. No extra round trips. No duplication.


  • Push only code needed for initial route
  • Render and make the initial route interactive
  • Pre-cache code needed for remaining routes using SW
  • Lazily import code needed for remaining routes from cache

Use WebPagetest in easy mode. Enable Lighthouse. Optimize for Time to Interactive. Shoot for 5 seconds. For great sites, shoot for 3.5s.

1.5s = 50KB per route.

If you use Polymer, you're left with 40kb.

They're calling this PRPL-50.

Factoring the UI

Get components from

Use elements for app components too.

It's all about custom elements, events, and properties. Use shadow DOM. How it does the rendering is an implementation detail.

It's easy to migrate from one set of web components to another set.

Managing State

The platform doesn't say a lot about that.

"Thinking in Polymer" proposes the mediator pattern. It's data down and events up.

This pattern is recursive.

Some people like the idea of a global mediator which contains all the app data. FLUX formalizes this concept.

Polymer is purposely low-level so that you have options.

Redux works well with web components.

Redux's developer tools are really great. Seeing the application state all at once is really great too.

Build your elements as generic elements with properties and events and then subclass them to connect to the store. Subclass as "connected" elements. Set properties in the "subscribe" callback. Dispatch "actions" in event listeners.

Ensure Redux logic is lazily loaded. This isn't entirely straightforward, but it's an important part of PRPL.

Lazily register reducer logic. Lazily load action reactors.

Polymer loves Redux. See "polymer-redux".

Serving for Production

Use minimal server smarts. Serve an app shell for routes. Use HTTP/2 push when possible. Use optimal code for the browser. Use SEO compatible output.

See prpl-server-node. It has client-side routing. It has presets that know which browsers need what.

It can also render HTML for SEO.

It's in beta.

lit-html: HTML Templates

Justin Fagnani, Engineer, Chrome


It's hard to build a great HTML templating system:

  • DX
  • Boot fast
  • Update fast
  • Bridge JS and HTML

It's a new library that they're working on on the Polymer team.

Polymer is moving away from HTML imports to using JavaScript modules.

For now, they're just moving the templates into JavaScript string literals using backticks.


  • HTML templates in JavaScript
  • Boots and updates quickly
  • Extrememly small
  • Easy-to-use and extensible API

Based on tagged template literals in ES6:

let templateResult = html`
render(templateResult, container);

It's similar to React, but different. It's just standard JavaScript syntax. There's no virtual DOM or diffing.

UI = f(state) (i.e. the user interface is a function of state)

You can pass a templateResult into another template.

You can use regular JavaScript. You can use map.

It supports promises too. You can embed a promise, and it'll show the result once it's done.

They use the <template> element under the hood. It's a container of inert DOM. They can be efficiently cloned to create new DOM.

Because they're working with the platform (tagged template literals), there are all sorts of performance efficiencies that they're getting for free.

Polymers scales O(changes). Virtual DOM scales with O(nodes). lit-html scales with O(expressions).

They're taking advantage of the fast, built-in parsing of the browser.

lit-html is really small. It fits on a single slide. It's 2kb.

It's still pretty early in the project.

They're working with the Marko Benchmark. It's amongst the fastest of the frameworks and among the smallest of the frameworks.

The API is really small. There's the html helper and the render function.

They have some directive functionality.

Using the until directive, you can show something until the promise resolves.

There's something called custom parts.

There's something called lit-extended that provides some nice syntactic sugar. It's 0.5kb.

They have a very focused API. It's templating only. Not a framework. No component model. Works well with web components.

It's working on all the major browsers, minus IE 11 (which is coming).

They're working on IDE support.

JavaScript Frameworks and Libraries Panel

Addy Osmani and Others, Developer Programs Engineer, Chrome

They're giving away a "very average" Moto G4 phone.

WebWorkers aren't used very much. DOMChangeLists could allow frameworks to use WebWorkers more.

Some people wish we had native Observables.

The AMP guy wishes we had really good weak maps.

Alex Russell said what he normally says which is that we build web apps the same way we used to build them for desktops. He said you have about 130kb for your page (minified and gzipped). How much of that is your framework taking?

The React team likes to think it's a library, not a framework. They try to not be too opinionated. create-react-app, Next.js, Gatsby, etc. try to fix this. The React team doesn't even use Webpack. He's really excited by Next.js.

Microsoft has 98 different projects that use Webpack, but none of them is the same. Interop between teams is impossible for them. He thinks Vue might help with this.

Web Components shine in that they are a good substrate for tying together different technologies.

Angular still doesn't spit out Web Components.

You can wrap a React component in a Web Component, but there are many performance reasons why React can't get rid of their own components and shadow DOM.

Alex says he doesn't think that Web Components have any bearing on whether you should have a virtual DOM. They solve some problems, but other problems remain to be solved. They do help with global coordination.

The AMP project took Airbnb's datepicker, used Preact, and used it for their own datepicker.

Creating Media Without an App

Mat Scales, Jennifer Lin, Peter Shin, Developer Programs Engineer, Chrome


The web has always been about sharing.

There are new APIs for the mobile web which allow you to create media.


@_jennylin and @peterdotjs from Instagram talked about how they use these APIs.

They started as a mobile app, but now they've created a PWA. They did this to focus on emerging markets.

You can take photos in their PWA. They even have filters.

The majority of these features are Android only, but emerging markets are almost entirely Android.

They're using Workbox.

Add to Home Screen

They implemented "Add to Homescreen".

It's best to pick when to show the user the add to homescreen prompt; disable it until you're ready to show it.

Adaptive Streaming

They're using adaptive bitrate streaming.

They used the shaka-player. It has a plugin system, and they've built various plugins.

Lazily create and make sure to cleanup.

Try to find that sweet spot for configurations.

Image Captures and Filters

<input accept="image/jpeg" …>

They used WebGL to implement filters.

They A/B test like crazy. When they first launched filters, their numbers dropped. It turns out, it was the performance hit that caused the drop because they saw the same drop when they did the work in a way the user couldn't see.

Doing things lazily really helps load time.

Offline Support

"What if every day was like being stuck at a conference with a really bad network connection."

They show a toast that when the device goes online again, the post will be posted. When the device goes online again, they get a notification.

There is an offline event, but it's unreliable.

They use a service worker with Workbox to capture the POST.

Media creation everywhere

getUserMedia gives you access to the camera and microphone.

The stream is limited to 1080p HD.

The new ImageCapture API is nicer and simpler.

There's also a new API called the MediaRecorder API.

Device performance is still a huge limitation.

WebAssembly video editor:

There's a shapes API hidden behind a flag. See

VR and AR on the Web

Josh Carpenter and Brandon Jones, UX Engineer and VR Engineer, Chrome




VR on the Web

WebGL, Vizor, babylon.JS, React VR, three.JS, PlayCanvas, A-Frame.

They're saying 2018 is the year WebVR goes mainstream.

VR is very fragmented. WebVR is the unifier.

Designing WebVR is pretty different than a 2D interface. Sketches help a lot.

Drawing inside Tilt Brush is an amazing way to sketch out your ideas.

They're working on a 2.0 version of WebVR. It'll come out in 2018. There will be a short transition period, but version 1.1 will be deprecated quickly.

Magic Window lets you peek into a VR experience without having the right gear. It'll now be a first-class citizen.

They're switching over to a prescriptive rendering model. It's now more of a framework you plug into. You don't have to build everything from scratch.

They're going to add a ray-based input system.

In general, they're taking the things that everyone was doing, and just baking them into the API so that they work by default.

They're going to build polyfills for backwards and forwards compatability.

They're going to require splash screens.

They want to encourage people to focus on mobile first.

Think of VR as a progressive enhancement.

WebVR is finally coming to desktop Chrome.

Discover WebVR experiences in Daydream.

Supporting libraries:

AR on the Web

AR is about bringing the digital into the real world.

Massively scalable: billions of nodes of content.

Display simultaneously, from varied sources.

Instant and serendipitous.

Safe, secure, and private.


The future of AR sounds a lot like the web.

Hundreds of millions of mobile devices will soon have basic AR.

AR Core.

These are experimental browsers that you have to build yourself.

Oldies But Goodies

There is a <ruby> tag used for something in Japanese. It was in IE 5, but it made it into HTML5. It's for when you need to say the same thing in two different alphabets next to each other.

Use <dfn> to define something.

There's also <cite> and <acronym>. Some of these are deprecated.

There's <var> for code variables.

There's <samp> for samples.

There's <kbd> for keyboard hints.

This really works: <body bgcolor="chucknorris">.

So does this: <bgsound src="example.wav" loop="3">.

<spacer type="horizontal" size="10"></spacer>

<center><font ...>...</font></center>

Chrome has an html.css with the default CSS. For instance, body has a margin of 8px by default.

She talked about <dl>, <dt>, and <dd>.

She talked about <select> and <optgroup>.

<mark> highlights some text (with yellow).

There are other things like <br>.

<nobr> is deprecated. Use whitespace: no-wrap instead. BTW, uses <nobr>.

<wbr> is a word-break. It tells the browser when it's okay to do a break.


Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p