[MUSIC PLAYING] PAUL COVELL: Good
morning, and welcome also to our live streaming audience. It may not be very early
where you are, so thank you. My name is Paul. I'm a product manager on Chrome DOMINICK NG: And I'm Dominick,
a software engineer on Chrome. We're here from Sydney,
Australia today. Are there any
Australians in the room? AUDIENCE: No! DOMINICK NG: Oh. Terrible. Why aren't we all
here in person? PAUL COVELL: Well,
before we get started, let's do a bit of
a show of hands. How many of you here have
heard of Progressive Web Apps? Oh, almost everyone. Fantastic DOMINICK NG: And how many
of you have actually built a progressive web app? Oh, fantastic. PAUL COVELL: Getting
to half, I think. Great. So for those of you familiar
with Progressive Web Apps already, we're going to
show you some of the things we're really excited about,
both what's happening now, but also what's coming down
the pipe on the road map. If you're new, and you're
thinking, what's all this fuss? We'll try to explain. We talk a lot about how
the web is universal, and that could mean
a lot of things. But what we mean today is
that anyone can publish and anyone can access
content on the web. You don't need to be
well-known or wealthy, and it doesn't
matter what devices your end users are using. And this was true
in the beginning, when websites were basic,
static, and images and text, but what's really interesting is
that it's remained true today, even as we have expanded
the capabilities of the web to do things like
rich media streaming, interactive graphics,
and really full web apps. You could still, more
or less, create it once, and your users can
consume it anywhere, on any device they
happen to have. This is really important,
as devices have really proliferated and exploded. So as a developer
today, you don't really have to think about the
number of places and devices and all the different
details that happen when your website goes
out and people consume it. Anybody can really access it. You've got hundreds of vendors,
hundreds of foreign factors, all sorts of different
geographies and industry niche. It just works. But there's one area where
this really isn't true today, and that's applications. If you're building
an application, you still have to think
about which platform it's going to be used on, and
you have to develop it once for every major platform. So one of our big
questions here was, why should this universality
only work for websites? Why can't we bring this
functionality to applications, so that as a developer, you
can make your application once and have it run on all
these different devices? So what all the
fuss is about is, we'll talk today about
how that's really starting to happen. And we're really
excited about that. But before we can really
talk about applications, we need to look at
what that word means. And we get this question a lot. People come up to us like,
great Progressive Web Apps. So what's an app? And everybody has
their own angle on it. So just to put a
stake in the ground, we'll tell you what we
look at as an application. So we take a step back
and look at the web. The web does a lot of
application-like things. Gmail and Maps brought rich web
apps more than 10 years ago-- 15 years ago-- and
ever since then, the Valley and unicorns
around the world have really leveraged this
to build their businesses. Rich web applications,
Amazon.com, Facebook, all these things. So today, it's a huge
part of the tech industry. But they still don't
feel like an application. They don't feel like
a Photoshop or a Word. So why is that? If we put apps up next to
what we said on the web, they stand apart in
a number of ways. You can launch them from
an icon on your desktop. You can launch them
when you double click the right kind of file. When you launch them, they
open in their own window, and that window
has a consistent UI that really makes it feel
like one person designed it. They can start up offline. Sometimes they don't do
much after they start up, but they can always start up. And they can take advantage
of all of the cool tech in the latest devices,
fingerprint readers and new accelerometers
and all that stuff. So when we look at
applications, these are the kinds of characteristics
that we think matter. And our goal is to
bring those capabilities to the web directly using PWAs. We want to break the
web out of the browser so that it can deliver
this app-like behavior. We're not really alone in
trying to crack this problem. If you look at technology
architectures like Electron, like Cordova, like
React Native, this is a common kind of desire. How can I use this
web technology to build native apps? PWAs take this idea
just one step further and actually build this
directly on the web. We want to bring users
the best of both worlds, and we want to
make it so that you spend less of your time fussing
with different platforms and more of your time and effort
on making your users happy. So how's that
working out so far? Dom is going to
bring us up to speed. DOMINICK NG: Thanks Paul. Let me take you back a few years
to the start of our journey with PWAs on Android in 2015. In a mobile-first
world, the mobile web was in a particularly bad
way, and users had clearly shown that apps were
their preferred medium on an increasingly
preferred device. Three key properties really
stood out about apps on mobile. Firstly, they often
had a far superior UI that was built with the
device and touch interaction model in mind. Next, on devices where
typing was difficult, having a home screen
launcher icon for instant, easy access was of
paramount importance. And finally, deep
system integration-- having the app show up in places
like share sheets, app lists, and settings-- was necessary to make an
app feel, well, like an app. Those last two in particular
are two of those superpowers that we just highlighted. So we leant on Progressive
Web Apps as a vehicle to level the playing field
for the mobile web. We focused on
encouraging developers like yourselves to build
touchable, mobile-first, responsive experiences
to address the UI gap. We went to work fixing
the system integration, ensuring that installed
PWAs interacted seamlessly with Android and other apps. We worked on lots of
the little details, making sure that the
app launched properly from push notifications or
from web links from other apps. Since then, our
core goal has been to use PWAs to allow you to
build an experience that's indistinguishable from native. We've definitely got a lot
of areas to improve on, but our work has really paid off
in adoption, user engagement, and developer success. Fast forward to today. All major mobile browsers
support PWA installation, even iOS. Now, we'll focus
mostly on desktop for the rest of this talk. But if you want to hear more
about the latest on PWAs on Android, you should check out
the talk at 12:30 on stage 8-- Taking Chrome Full Screen
with Trusted Web Activities. Back to the history. While mobile is now a
dominant consumption platform, desktop remains the
dominant creative platform. We knew that
transforming that success on mobile to success
on desktop would require significant
additional investment. Well, we made that
investment, and we're excited to announce that
as of March this year, we now support installing
Progressive Web Apps and running them as
standalone app experiences on all current platforms. [APPLAUSE] Chrome OS was the
first desktop platform to get support in early 2018. We took the time to
re-imagine the UX for desktop, settling on a themed title
bar, a three-dot menu to access useful browser functionality,
and the title bar serves as a security
surface for us, where we can disclose
things like permissive usage and anchor prompts for features
like autofill and translate. We followed Chrome OS
with Windows and Linux support in late 2018. For both of those, we
retained the title bar design, with the window
controls matching the style of the host OS. With Linux, showing the
app icon in the title bar. And Mac support was
shipped in March this year with the familiar left-aligned
traffic light window controls and centered app title. Now it's possible to
do things like this-- here, you see SketchUp
Web, a 3D modeling tool running as an installed PWA
and looking native on all three desktop platforms-- one code base. We're really excited
about the possibilities that this opens
up for all of you. The web is no longer
confined to the browser, but open as an app
platform, where you can make native experiences available. Write once, run anywhere. Let's make this a bit more real. I'm going to walk
through an introduction to the key ingredients
of Progressive Web Apps. For many of you who've
built them before, this is going to be familiar. And for those of you
who are new to PWAs, it'll hopefully give you a great
starting place to build on. But if you take nothing
else away from this talk, just take this-- PWAs are just websites with
a few additional pieces. Being websites, they should work
perfectly well in the browser-- any browser-- and,
being the web, these additional pieces
also work in the browser. Users should never have
to install a PWA in order to use its capabilities. But taken together,
these additional pieces are the progressive in
Progressive Web Apps-- the ability to be installed,
to function while offline, and to access the APIs
and operating system integrations that create a
compelling app experience. Even better, these pieces-- all the code that I'm
about to show you-- works on mobile and desktop. The look and feel is
tailored to the platform, but it's the exact same
code, cross-platform and cross-browser. And that's really the power of
the web, why we do what we do. We might take a little
longer on the web platform to deliver capabilities
and integrations, but when we do it,
it's done universally. So let's start with the
first puzzle piece-- the web app manifest. This is a JSON file linked from
your page's header element. It provides application
metadata that's used for a variety of purposes. Note that we usually
expect the manifest to be retrievable without
needing to attach credentials to the requests. If that's not the
case for you, you'll want to add the
crossOrigin attribute to your manifest declaration,
and that will cause the browser to make a credentialed
request for the manifest that attaches things like cookies. Here's an example manifest that
our team built for squoosh.app. It's an image
compression PWA that lets you access all of
the advanced options offered by native
image compressors, but right in the
browser, meaning that you can use it anywhere. By the way, if you
drop by the web sandbox you can see Squoosh
in action and hear about how it was built.
Or just visit squoosh.app if you're following
along on the live stream. Let me highlight a couple
of the key fields in here. The name, start URL,
and icons members are used to create the
launcher shortcut for the app, and the display member tells
the browser how the app should be open when it's run. By specifying standalone, this
requests an app window that's independent of the browser. There are a few other
display modes available, but standalone is the one
you'll likely want for your PWA. To make it a bit
more real, here's the launcher icon in
the applications folder and in the dock on a Mac after
I've installed squoosh.app. And then when I use one
of those to launch it, it's going to open that start
URL in its own app window. This theme_color member provides
the color for the app title bar when it's launched on
both mobile and desktop. That's this orange bar at
the top of the window here, and that's going
to give your app a distinctive
on-brand experience. But don't worry. If you omit the theme
color, the browser is going to choose
a neutral color that fits into the OS theme for you. And finally, the
scope determines the extent of the app. This is important for accurate
link capturing behavior, where the browser can intercept
navigations that fall within the
scope of your app and then redirect those links
to open in your app window. I'll talk a little bit
more about link capturing and what we're doing there
later in the presentation. Now, we're continually
adding new members into the web app manifest to
help define new functionality. But what's really exciting
is that, as of 2018, last year, all major
mobile browsers now respect the web app manifest
for their "Add to home screen" functionality, and we're
seeing an increasing number of desktop browsers
doing the same as well. Here, I've got a screenshot
of Duo, our video calling PWA, running in a standalone
app window on Chrome OS. You can see they've used
a neutral theme color, and the app icon appears as the
running app in the Chrome OS shelf. Now, let's move on
to Service Worker. This is the secret
sauce for offline-- a lightweight network proxy
that intercepts network requests and provides case resources,
should those network requests fail. This is the technology
that truly allows websites to break out of
that online sandbox and work seamlessly offline-- technology that lets your
websites always be apps, and not turn back
into a web browser tab when the network is down. The advent of Service Worker
represents a fundamental shift in how you should think about
architecting your websites and your web apps-- offline first, rather
than online first. We've seen time and
time again that building your app from the ground
up with offline in mind works way better than trying to
retrofit offline functionality after the fact. And just like the
web app manifest, all major browsers now ship full
support for the service worker API. There is no reason
for modern web apps to not be built offline first,
just like native apps using service workers. Let's dive into what
that looks like. I'm going to walk
through how you can use Service
Worker to provide a simple, offline
fallback page in place of Chrome's offline page. This is an easy way to keep
showing users your themed app UI when the network
isn't available. First, we wait for
the page load event to register a service worker. And that's to make sure we
don't block the page load. Once registration is
complete, the commands in the serviceworker.js
file are going to be run. You can specify
an optional scope for the service worker that
denotes the extent over which the service worker has control,
the navigations that it's going to be intercepted. This should definitely match the
scope in the corresponding web app manifest file, to
ensure that the service worker controls all of
the URLs in your app. So let's move on to the
service-worker.js file. In here, we wait for the
install event to fire. And note that this
doesn't have anything to do with installing a PWA. We're going to get
to that in a moment. This just means that the
service worker is ready to go. At this point, we can create an
offline cache using the cache API. You'll notice that I've
versioned the cache name so we can easily invalidate it, should
the content become out of date. So once we have a cache open, we
just pass it a list of the URLs we want cached. And then the cache will go
and fetch those and store them ready for use later. The cache itself
maps keys of requests to values of responses. In this example, I only
need to cache the one page, because the entirety
of that page-- assets, styles,
contents, and scripts-- they're all contained in
that one HTML file inline, and no other network requests
will be made whilst loading. So now we've got
that page cached. We need to ensure that
we retrieve and serve that page when the
network is down. And we do that with a
fetch event listener, which will be fired for
every network request made by your site. This allows the service worker
to intercept all those network requests and substitute
them, if necessary. Now, I've omitted a couple
of details in this example that you'll want to look
at, like cache invalidation and navigation preload to
ensure good performance. So when that fetch
event fires, we're going use a network-first
strategy in this example. We're going to respond
to the fetch event by calling the fetch method,
and that sends the request to the network. Should that network request
fail, we'll catch the error, open up our cache, and
serve the offline page that we stashed
earlier, ensuring that the user is presented
with app-theme UI at all times. Now, this is an
incredibly simple example of offline support. It is the bare minimum
that you can do. We're not even bothering to
cache specific resources, just a single page to display when
the network is not available. You can, and you
should, do a lot more. And many of our
partners have done so, creating cache-first
loading strategies where important content
is always available, and important user journeys are
always accessible, no matter the network status,
buffering new navigations for syncing with
the server later on. Now, Service Worker is an
extremely low-level API. You probably want to avoid
writing all of this caching yourself if you can avoid it. And of course,
being the web, there are plenty of libraries
to help you out. One that we really
like is Workbox, which wraps the
Service Worker API and protects you from
some of the dark corners and sharp edges. And it also means
you can avoid having to write your
caching file by file and, instead, use cache
all routing paths. Here's an example of how
powerful and flexible Workbox can be. I'm using the routing
library to specify that CSS files should be cached
with a StaleWhileRevalidate strategy. That means that when
we load a CSS file, we race the network
and the cache, and whichever one
gets back first, we send that response
straight on through. The first time, the
network's going to win, because the cache is empty. But then that request will be
transparently and immediately saved in the cache. And from that point on,
it'll be available offline. You can find out more about
Workbox at workboxjs.org. It really makes developing
powerful offline-capable web apps easy. And Paul's going to
show us one in action. PAUL COVELL: So we've
actually started to use some of these PWAs to
ship some of our core apps in Chrome OS. And we used some of the
goodies that Dom mentioned. This application uses
Workbox and WebAssembly. So I recorded a
video of Canvas-- this is our drawing app-- to show you how it can
work completely offline. So this drawing was done
by a colleague of mine using this app. When I was planning the
talk, I asked around to see if we had any cool
illustrations that we could use. I was expecting something
living up to my high standards, like a box or a circle. But this is what I got, so this
is what we're going to go with. So in this video, first,
I turn off the Wi-Fi, and you can see that,
once I turn that off, there will be no more
network connectivity. And then the artist uses the
stylus on a Chrome OS tablet to sign his name. And the key thing here is
he didn't know anything about the offline status. He doesn't care whether
it's connected or not. He just uses the app
the same way regardless. And the service worker
syncs it up next time the device connects. DOMINICK NG: Thanks, Paul. So once you've got
a web app manifest and an offline-enabled
experience powered by service workers,
you can add your own UI to prompt users to install your
PWA, turning it from a website into an installed app. We strongly recommend
taking advantage of this. On desktop, app discovery
still overwhelmingly runs through search and
download links. Replacing those download links
with a PWA installation prompt allows for a smooth,
seamless installation experience and transition into
an app window for your users. That means you're not relying
on users finding the browser's own installation prompts. Installation is a
powerful operation, since it gives your site
a permanent presence in the user's launcher. So when your site
loads in the browser, Chrome runs some
checks to determine if you're eligible to
prompt for installation. Now, your site
needs to be a PWA-- so have a manifest,
have a service worker with offline functionality--
and you'll also need to have seen some user
engagement, since installation prompting shouldn't just happen
the first time a user visits your site. When your site passes
those checks, which could be run dynamically
through the lifecycle of the current page load,
the beforeinstallprompt event will be fired into
your top level frame. You'll need to add a listener
for this event on your window object. First stop-- that
event handler needs to stash the event away
somewhere that's accessible later, since you'll need to call
the prompt method on the event to actually trigger
installation. Putting the method
on the event ensures that the user can't get
an installation prompt unless the browser has verified
that the site is eligible. beforeinstallprompt
firing is your cue that you can enable UI in your
app to ask the user to install. For this simple
example, I'm just activating a disabled
installation button when the event fires. But more broadly, an
installation prompt usually works best if you
have some UI to tell the user what's going to happen
if they choose to install. And we've got a demo of
what a good example of that looks like coming
up in just a moment. Finally, we wire
up a click listener on that now-activated
Install button that calls the prompt
method on the stashed event. This is what
triggers the browser to show the installation prompt. Without that click, which
signifies user intent, the prompt method is
going to reject and not show an installation prompt. The event also has a
userChoice promise [INAUDIBLE] that will resolve with the
user's response to the prompt, whether they accepted
installation or not. Another useful
event to listen to is the appinstalled
event, which will be fired if the app
installation is triggered and successful from any source. Now, that includes
beforeinstallprompt, but also mechanisms that the
browser might offer, such as the three-dot
menu prompt. PAUL COVELL: So you can
see this come together in a few mainstream apps. I'm using Spotify on
my Chromebook here, and you can see that there
is an install app link on the left-hand navigation. When I click it, you see the
familiar confirmation dialog. And then, boom, it's
installed in my launcher and in its own window. [APPLAUSE] So this, as you can see-- thank you, Spotify. You can see this is
how you can actually integrate these
beforeinstallprompt events that Dom is talking about to
encourage your users to install at the right time. Now, one thing that is
visible in that earlier video, but you'd have to really
be looking for it to see, is this little plus
in the omnibox. So this is a feature coming
in early August with Chrome 76 that we're super excited about. This means Chrome
will actually promote your PWA in its most prominent
UI space in the omnibox. This uses the same trigger as
the beforeinstallprompt event, but you don't need to
do any coding to get it. It's just intended to
be subtle and clear-- this website is also an
app that you can install. So let's see how that works. In this video, I'm
installing the PWA of Duo, which you saw earlier. You can see how it works
with just a couple of clicks and really no download time. I have an app on its
own window, and I can use it to make a call. So now that you've seen the
technology in action, let's look at how it can impact
your users and your business. Hulu is a popular streaming
platform here in the US. You can watch TV and movies
at home on your big screen or on the go on your
phone or laptop. If you were a Hulu user
with a Windows machine, you could use their native app. But their native app had poor
user reviews and poor usage, and Hulu started thinking
about how to fix it. They already had a
world-class web experience. What did they decide to do? You guessed it. They built a PWA. So here you can see
the Hulu PWA installed in Chrome OS on tablet mode. It looked good, so
they launched it. Within three months, 96%-- nearly all of their
legacy users-- had switched to
using this instead. So far, so good. Even better, compared
with the website, Hulu saw that
users who installed the PWA were coming
back to it more, and they were
watching more videos. A whole lot more, in fact. It's still early in our
experience here with PWAs, but this does fit the
pattern that we're seeing. Because it's in the launcher,
it's easier to remember and more natural to
return to this experience. It's also an immersive
full-screen experience. So if you're engaged
in the activity, you're more likely
to keep doing it. So if you have dedicated
repeat users on your website, this same pattern
may hold for you. DOMINICK NG: Thanks, Paul. Just some amazing
numbers there for Hulu. So it's really impressive what
the app-like web can do today-- cross-platform, cross-browser,
from one code base. Now, I was talking to some
folks around IO this week, and some of them
were really surprised to learn that the
web can already do a lot of these things-- access camera and
microphone APIs, use USB and Bluetooth
devices, or run cross-compiled
performance-critical code in WebAssembly. We've come such a long
way in the last decade. But we're not stopping here. We know we've got
a lot of work to do to continue to expand the
capabilities of the web and further improve
our OS integration. I'm super excited to share
some of our upcoming road map, all of which is
being developed out in the open in close
collaboration with partners, developers, and other browsers. We are hard at work on
a native file system API that will let the web,
mediated by user consent, directly read and write to
files on the user's disk. Not a virtual file system,
but the real file system. And we know that this access
is one of the biggest remaining holes in our integration story. It's particularly vital
for porting existing creative applications to
the web and for enabling web native creative
applications like SketchUp, which we showed earlier,
to become even more useful. Alongside this, we're
working on new web app manifest declarations
and APIs that will let PWAs
associate themselves with files and MIME types. That means that when
you double click a file, it can open in an installed PWA. This will further empower
creative applications that have shipped on the web. We're also working on new APIs
for PWA launch management. Right now, we do some basic
link capturing on Android, where URLs within the scope of
your PWA will open in your app. Now, that works well
there, because there's only ever one instance of
the app on Android, and changing state in response
to a link is expected behavior. But on desktop, that doesn't
quite make as much sense. You might want
different behavior based on the content
of that link. We're creating a new
launch event that will be fired into a
PWA's service worker upon an incoming
navigation, allowing you fine-grained control
to open new windows, focus existing windows,
or post message the incoming data into
an existing window. But that's not nearly all. I've picked out several more
of our top priority APIs that are currently under
development in Chrome. Of course, the dates
up on the slide are tentative and subject to
slipping if we need more time to get things exactly right. But with luck, we're planning
for all of these APIs to ship in Chrome this year. First, origin trials
for your feedback before making it to stable
a few versions later. Those three APIs that I
mentioned-- native file system, PWA file handling,
and launch event-- should all make it to you
by the end of the year. It's incredibly exciting
how many new capabilities we're bringing,
and we really want to hear from you to make sure
that your needs are being met, or how we can do
more to meet those. Importantly, with all
of this new API work, we don't want to break the
web and lose the existing advantages of our platform,
our universality, our security, and our privacy guarantees. We're working carefully to
close the functionality gaps in the right way, collaborating
with other browser vendors and working out in the open to
solicit and act upon feedback from partners and developers. We're working incredibly closely
with security and privacy teams to make sure we don't lose
those guarantees we've worked so hard to build into
the web platform, to keep users in control and
aware of what is happening. Our capabilities work
is really pushing the boundaries of the web,
adding much, much more native functionality. But we're focused on doing
this in the right way, in a way that doesn't create
fragmentation or prevent other browsers
from following us. PWAs marry the web with
native experiences. We want to let you show off
the best of the web platform and build products
that delight users, no matter where they are in the
world or what device they use. Empowering the open web empowers
you, granting the widest reach from a single code base. So how can you get started? You can make web apps. You can make them
offline first, turn them into PWAs, leverage installation
and system integrations, and take advantage of the best
of the web and native worlds. Hopefully we've shown you just
how compelling Progressive Web Apps are as a
universal app platform and how much more
compelling they're going to get over the next year. PAUL COVELL: So thank you
for coming to the talk. [MUSIC PLAYING]
