[MUSIC PLAYING] STEPHEN FLUIN: Good afternoon. My name is Stephen Fluin,
and I am a developer advocate on the Angular team at Google. Throughout my career,
I've been entranced by the power of tools. The right tools used
in the right way have the power to improve
our lives as developers, but also to increase
the quality of our work. Part of the reason
I joined Google was to help developers
find and adopt great tools from across the ecosystem. Over the past day
or so, we've heard a lot about progressive
web applications. Part of what we've heard has
been some of the great case studies about the
outcomes that we get from adopting
these technologies, and we've also heard
about some of the ways that these improve
the user experience. I want to peel back the onion
a little bit now of PWAs and get into a little bit
of the tooling, the ways that we build progressive
web applications and the way that tools can help us do that. I'm going to go through this
in basically four parts. First, I'm going to start off
with a introduction to kind of the state of progressive
web apps as they are today. Then we're going to go
ahead and dive into some of the goals of the tools. Why do we build these things? What are the philosophies
behind these tools? Then we'll talk about
single page applications and the libraries and
frameworks that exist today to use these things. Then we'll end with
some best practices that you can take back with
you as you start adopting some of these tools, and as you
look at adding progressive web applications to your workflow. So let's start by looking
at the state of PWA tooling as it is right
now in September of 2017. We're all chasing after
the perfect progressive web application, but
a lot of us come from very different journeys. Some of us already have
large applications. Some of us have
Greenfield projects where we can experiment
and try new things. But when we talk about the
perfect progressive web app, I like to think that we're
talking about three things. We're talking about building
applications that are fast, reliable, and engaging. And when we combine this with
thinking about the tooling that exists for us as
developers, we're really looking at how do
we get the best developer experience for providing our
users the best experience, the best DX for the best UX. So what can tooling
do to help us with all of these different problems? Well, when we talk
about our users, their time is very,
very important. As we've heard many times
throughout the conference, even seconds or
milliseconds of time that you make your users
wait for your application, or for a piece of
the functionality, can cost your business money. It can lose you
conversions every time. We also talk about bandwidth. In many cases, and in
many user environments, the amount of bandwidth
that your application takes is a direct decision
factor in terms of whether or not they're going
to use your product or service. Additionally, tools can do
some very interesting things. By giving a tool an
understanding of the browsers that you're looking to
target, and by combining that with an understanding
of what tool or browser the user is using to
access your application, we can send down just the
right code at the right time. Additionally, push notifications
are a really great way of building
engagement with PWAs, and tooling can help us
understand these things a little bit better. As developers, a lot
of the time we're writing code and
maintaining code. And so using PWAs to
generate code for us, or using tools to
generate code for PWAs, can be a huge impact
for our lives. And lastly, tools
really focus on allowing us to take advantage
of best practices by giving us a deep
understanding using tools like Lighthouse that expose,
from across the industry, the best practices that have
been collected by the Chrome team. Some of the
technology behind PWAs include the web app manifest,
which we'll talk a little bit about, the service worker,
which I'll talk a lot about. But a lot of this is
going to come down to you building
great applications. Tools can only do so much
to help you advance and take advantage of the latest
and greatest capabilities of the browser,
but you still need to be thinking about
your use cases. You still need to be
worrying about your users. So let's talk a little bit about
the web application manifest. The web app manifest is
really designed to try and let both browsers and
the web at large know about your application. We're really trying
to elevate the code that we write from
a single page that's going to be served at a single
time, or a set of JavaScript and HTML, into the concept
of a collective application that we know something about. It has themes. It's got icons. It's got a starting place. We can tell the
browser of the device how it should be
accessing our site and how we should be
presenting it to the user. Some tools can do things
like default generation. They can give us a manifest that
we can then easily configure. Other tools will
actually guide you through the entire process
of making decisions. Service workers are the
underlying API in browsers that give us these kind
of modern superpowers for building progressive
web applications. By adding a service
worker to my app, I can do a lot of
very cool things. I can proxy and intercept
all of the HTTP requests that my application makes. By doing that, I can
decide when and where I want to be serving from the
internet, from a local cache, or maybe even some
generated content that I'm storing within
my service worker. But service workers have a
relatively complex life cycle. And as we think about
things like caching, each of these things can be
done at any of these stages, whether it's when the
user first visits the page and we're still rendering
from their HTML, after the service
worker's been installed and were given a chance
to actually go and cache these things, or even
later, maybe when a user is visiting a
page for the second time or the third time. We can make decisions at each of
these points of the lifecycle, but tools can help us
make those decisions. So let's talk about one specific
case, which is file caching. As a developer, we
can decide, hey, I want to cache all of the
assets from my application, maybe as part of the
installation process, because it's so
important to my app. Or maybe I see caching as a
nice to have for my application, and I want to install
after the application has installed my service worker. This can be helpful by taking
some of the work that's being done by the browser
out of the critical path for rendering, giving
users a great experience. We can also do things
like runtime caching because we don't always
know all of the data our application is going
to need when we write it. A lot of data is coming
from servers and back ends, and as the user
accesses them, we can decide, hey, I'd like
to cache these things so that if my user
does go offline, they're able to access
all of the content that they've previously seen. Finally, there's also
advanced caching strategies, because by combining our
knowledge of our applications with our tools
knowledge of the user, we can actually do far more
advanced things that really drive great user experiences. Another technology
that we really want our tools to help us
with is push notifications because as developers,
there's a lot of work here that can be done if we want
to take advantage of it. And there's best practices
that the browsers are leaning towards. One of these best
practices is that we want different behaviors
for push notifications, whether we're using the
application actively on the device or whether the
service worker's being woken up behind the scenes
when the user is not interacting with our device. When the user is not
interacting with our device, we actually want to
show a notification. But there's some
additional things we can do if the
user is live and engaging with your application. These sorts of best practices
can be baked in via tooling. Another thing that
I care a lot about is code generation,
where we want to give you the code
that's going to help you get your work done faster. Good tools that do
good code generation are going to be fast
by default. They're going to be great by default.
And they can even do things like help you with your
build pipeline, so help you write code and ship that
great code to your users with all of the sorts
of metrics and things that you need to understand
how your users are going to consume your applications. I see code generation as
a very interesting idea because it combines this
ability to give a developer a great experience by
default without eliminating any of their
flexibility or control of what they actually
ship to users. So when we talk about PWAs,
there's a few different ways that Sam talked about
yesterday in terms of building them and adding
them to our existing workflow. He talked about, maybe
I'm going to write a new app from scratch,
taking advantage of PWAs. Maybe I'm going to rewrite
one feature of my application and take advantage
of PWAs fully. Or maybe I want to
look at it a little bit differently and
add one PWA feature to my entire application. Things are a little
bit simpler when we talk about both the generic
tools and the framework- and library-specific
tools because typically, as a developer, I'm targeting
that library or framework for my entire application. And because of this,
it's much easier for us to take the best of PWA
and apply it holistically to an application
all at one time. But it's still possible
to take advantage of some of these tools and
build a fully custom service worker or PWA implementation
that follows my business needs and the needs of my users. One of the really
fantastic tools is Chrome and the
developer tools that we've been
building into them. I'm going to come back
to this a couple of times because the Application
tab in the developer tools is one of your best
assets for understanding what's going on when it
comes to building a PWA. It's there that you can bypass
the service worker for network calls so that you
make sure you're getting the most fresh data. You can understand
the lifecycle. Is there a service worker
that's pending install? Is there one that's
already been installed? What's the state of my cache? Can I look and see what has been
cached and what its status is? But Chrome developer
tools are also very awesome because we've baked
in some of these awesome tools for finding best practices
such as Lighthouse. So now, using
Lighthouse, I can figure out am I building a great
progressive web application? Is my application doing
well on performance? Can I broaden my audience
by taking advantage of more accessibility best practices? And overall, what
are the practices that we've discovered
from across the ecosystem that I could be taking
advantage of in my app? So we have a few generic tools. So these are tools that
could be used for any web application that exists today. And one of the best for
doing this is called Workbox. So this is a project
from the Chrome team that takes the
best of what we've got in terms of our
understanding of the use cases and the needs of developers,
and packages that in a very easy-to-use library. Workbox is fantastic in the way
that it embeds offline caching, even newer things like
offline analytics, and new APIs that are now
coming available in browsers such as background sync. Background sync is a
very important concept because it allows us to not
only get the freshest data when a user is interacting
with our application, but we can do some of
that behind the scenes, so that the moment our user
accesses our application, even in offline mode, we can still
give them the freshest data that they expect. I love Webpack. There's a lot of
different tools out there for building
applications with Webpack that have PWA attributes. One of these is Offline
Plugin for Webpack. Offline Plugin really focuses
on the file caching aspect of service workers and PWAs. With Offline Plugin, you can
do ahead of time caching, so give me all my
files up front. I can do deferred caching. Hey, let's go and get
these files later. Or I can make some
of my files optional and base these sorts of
decisions on user behavior in order to cache the
files at the right times in the right way. Another fantastic
project that you should look at as you're
getting to know PWAs is actually from Pinterest. It's on their Github
pinterest/serviceworkers. This is a collection
of utilities for creating, testing,
and experimenting with service workers. Not only do they have
code generation tools that give you a service
worker under the hood that helps you move faster
as a developer, but they've also done
something very interesting. They've built out
a mock environment generator that allows you to
do testing of your service workers. And this has historically
been a little bit of a problem because
of the newness of these APIs and the way
that sometimes the browser's actually ignoring the back end
of your application entirely. And so mocking out these
sorts of environments and testing them can be
very important for ensuring that we have fantastic
user experiences. Another tool that you should
be aware of, that you're just going to see all
over the place, is a set of tools called
sw-precache and sw-toolbox. This was another set of
tools from the Chrome team that were utilities for
building service workers. These tools had the same
goals and values as Workbox, but they were a little bit
less modular, flexible, and extensible. And so the team
decided, hey, we want to collect this array of
tools that we've built. We want to reflect
on the best practices that we've learned over
the past few years. And we want to bake
those into the new tools. So sw-precache and sw-toolbox
have, for the most part, been replaced by
Workbox if you're building a generic
implementation of a PWA today. But what you'll see is
that sw-precache is still used by many CLIs today, and
it's still a fantastic tool for building PWAs. Another tool to have
in your tool kit is Hacker News
PWA, or hnpwa.com. This is a website where
we're collecting the best practices across a number of
different tools, libraries, and frameworks for building
progressive web applications. For each submission, we track
both the speed as well as some of the capabilities of it. There's tools from projects like
React, Firebase, and Angular. There's more than 20
implementations of this Hacker News client, and they
really tried the best to show off the capabilities
of the framework and of their PWA capabilities
in a way that's open source and that you can take
advantage of and learn from as a developer. So now let's get into a
little bit about the goals and the philosophy
behind these tools. I like to think that
technology tools are really about simplifying the
mental model in a good way. It's very easy to do
this wrong, because what we're doing under
the hood is we're finding new abstractions
for concepts that have existed before in lower levels. But we, as
developers, can't hold all of the complexity in
our heads at one time. We have to focus
on smaller subsets of the projects and
the tasks that we're trying to accomplish. And tools are fantastic
at taking an abstraction and saying, here is the thing
that I can help you with. Additionally, tools can help
you with different edge cases. And finally, tools can
help you save time. Let's dig into these
little bit more. So when we simplify
mental models, this is something that
we often have to do. One of the common
programming jokes is that there's two
unsolved problems in computer science,
naming things and cache and validation. Caching is a very,
very hard topic. And so if we focus, via
tools, more on use cases than underlying
implementation, the tools can actually help us
with that a huge degree. The service worker
lifecycle I also find to be a little
bit difficult. And so again,
focusing on use cases, the tools can help us with that. The last thing is an
interesting conversation that I often have with
developers, which is, does web development feel
like what I'm used to? We're always
mapping new concepts into concepts that
came previously for us as developers. I know that I talk
to developers that are in some ways stuck
in the web development that we did five or six years
ago because they haven't been able to take advantage of the
newer capabilities that we have and the new APIs that
exists in the browser. And so good tooling
should both be teaching you these mental
models and kind of guiding you into the new world while
still empowering you to be effective from day one. There's also a lot
of edge cases that end up coming up
that you might not expect when you start using
progressive web apps or service workers. So a lot of us have talked
about intermittent connectivity in offline use cases. So one of the things that
can happen very easily is what if your app loses
connectivity during the service worker install? A naive implementation
that you might do yourself might
fail out and say, hey, I can't use
any of these assets. Let's uninstall. Let's throw away
everything we've got and then try again
on the next load. But you could also do
something different. Some of the tools will
allow you to, for example, keep some of the cache files
via some sort of validation. They're using some
sort of checksum to ensure that
they've got the files and they understand the
integrity of those files. We've talked about a lot
of offline use cases, but there's also
online use cases. What if your user has
full connectivity? One of the patterns
that's been emerging that I believe is a little
bit of an anti-pattern is this little box at the
bottom of the page that says the application is updated. Click to refresh. And so this is something that we
didn't used to have on the web because applications were always
fresh when you loaded them. But now, in the
modern web, because we have these new
capabilities, we've introduced a little
bit of a problem where if I update my
application every day, perhaps via some sort of continuous
integration system, I don't want my user to
be constantly assaulted with this click
to refresh, click to refresh just so
that they're getting the freshest content of my app. We also build applications now
in much larger environments. Many times you may be building
a front end of an application, but you have no control over
the back end of an application. And so as you're looking
at adopting things like service worker, you may
want to be caching files. But maybe the cache headers that
are coming back from your API aren't what you expect
or aren't what you need to build out the front end. So you can look at things
like tools to say, hey, maybe I need to override
the cache headers, or I need to ignore them and
I need to supply a completely different policy that supports
my front end in a way that my back end can't? And then finally, we
talk about saving time. As developers we
write a lot of code. But we also have projects
that have a lot of DevOps. It's not just as easy
as writing code anymore. I have to figure out how
am I going to minify this? How am I going to build this? How am I going to combine
this all with the work that other developers are doing? And then how do we ship
that down to the user? And all these things
have lots of effort, and so finding the
right abstractions and the right tools at each of
these stages is very important. So now let's get into the world
of single page applications. So libraries, frameworks,
and platforms, oh my. So I'm going to go through
these five specific tools. I apologize to anyone
that's not on this list. There are more tools than I can
count and more frameworks them I can go over in the
limited time we have. But each of these share
a number of things. So each of these tools
use some sort of CLI in order to empower developers
to be more effective, more quickly. So let's go into each of these. So in the React world,
we have Create React app, which is a fantastic CLI. If you're using this CLI,
what you're going to see is that it creates a
service worker and a web app manifest by default. They
have a cache for strategy under the hood to ensure
that you get the fastest experience possible. So for all of these examples,
I'm going to use Yarn. You as a developer could use NPM
or any other package management tool that you want to go fetch
from the NPM repositories. But installing Create React
app is yarn global app, so you globally install
Create React app. Then I'm going to
run Create React app and give it a project name. Then I'm going to
CD into that folder and I'm going to
run a build command. What this will get me is a
basic kind of Hello World, welcome to React
application that is awesome in terms
of demonstrating how do we get
started very quickly, and then giving developers
the freedom and flexibility to get into their application
and start adding functionality right away. And one thing that is
very beautiful to see is that the moment you
see that application in your web browser,
a service worker has been installed and loaded. So it is a PWA out of the
box in a very fantastic way. Let's now talk a little bit
about the Preact project and the Preact CLI. This is a CLI that goes
a little bit further in terms of helping
developers take advantage of the modern web. It has the standard
app creation, but it will also do things
like generate an app shell for your index.html file. Because it has knowledge of
some of your application, it can ensure that that
is pre-rendered as HTML, and then you ship that
down to the browser to increase perceived
performance, which is a very important metric. The Preact CLI is
also browser ware, so if you tell it which browsers
you want to be targeting, it can automatically add
the appropriate prefixes for your application. One of the things that's
fantastic about the Preact CLI is that they've pre-configured
your application if you run the appropriate
commands for Firebase Server Push. So combining, again, its
knowledge of your application with its knowledge of the
best practices across the web in terms of which files should
be pushed down of the browser, and which should be waited
for or requested only when it's needed by
the user, and then baking that into the Firebase
hosting configuration. All the Preact CLI is using SW
pre-cache under the hood today. So just like we saw
before, I'm going to add the Preact
CLI via the terminal, and then I'm going
to run Preact Create and give it a project name. And again, I'll just CD into
the folder and run the build. And here, out of
the box, we're going to get a beautiful,
material designed, styled app, Hello World. And one of the cool things
about this application is it actually includes
routing by default, so you can see one of
these very common patterns and get started more quickly. Next I want to talk a little bit
about Polymer and the Polymer CLI. Polymer does things a
little bit differently. So while they have the
manifest generation and the optional service
worker, they actually do a set of
distributions for you. And this is something
that's unique to how they've built their CLI. So when you run a
build, you won't just get a single set of
JavaScript that you ship down to the browser. They actually give
you three options. So they're going to
give you an ES5 bundled version of your
application, which is the standard
version that will work in basically any browser. But you also get an ES6
version, or an ES2015 version that is a little bit smaller,
a little bit more performant if the browsers have optimized
for ES2015, which most of them have. But then you also get
an unbundled version of that same code. And the idea here is
that they're really trying to help you take
advantage of the latest and greatest from the browsers,
and kind of leaving behind some of the legacy
that we had to support with ES5 in the past. One nice thing, as well
about the Polymer CLI is that they have
purple by default, so they really believe in this
idea of building great user experiences. With the CLI for Polymer, I'm
going to install Polymer-CLI. I'm going to make a new
directory and CD into it, and I'm going to
run Polymer Nit. And then when it's
going to give me is a set of choices of which
starter kit I want to use. So there's several options. The one here that includes
PWA out of the box is called Polymer 2 starter kit. And then as soon as I've
set up that project, I can run Polymer Build. Again, I'm going to get an
application with routing and some material design
styling that, out of the box, gets me started much quicker. And as we always
like to see, it's service worker out of the box. Next I'm going to talk
a little bit about Vue. So there's two
projects at play here. There's the Vue CLI as well as
the Vue JS Templates for PWA. Again, this handles
app creation. It handles manifest and
service worker and app shell generation. And one of the very nice
things about the Vue CLI is that it intelligently loads
the bits of your application as they're needed. So it can understand,
for example, if you have lazy loaded routes,
which chunks, based on the user request, we need
to load right away and which ones can be
asynchronous and deferred for a little bit later. Using the Vue CLI is
relatively straightforward. I'm going to install
the CLI, and then I'm going to run Vue and
Nit and I'm going to choose the PWA
template, and then I'm going to give
it a project name. The Vue CLI is fantastic
in terms of the way that it gives you
a guided setup, and so it's going
to be asking you questions about your
application and how you want to be serving
your users in order to, as you're going, teach
you the different decisions that you have to
make as a developer. The Then I'm going to
install the dependencies and I'm going to run
another build command. And out of the box, we have
this very helpful tutorial that says, hey, here's
some links that will get you started
as a Vue developer. And again, we have the
beautiful service worker. Lastly I'm going to talk a
little bit about the Angular CLI. The Angular CLI
handles app creation. It also handles service
worker generation. One thing that's a little bit
different about the ANgular CLI is instead of using JavaScript
to configure your service worker, it has a
declarative JSON based configuration file called NGSW. Another thing that's
interesting about the Angular implementation and
support for service workers is that they've wrapped push
notifications as a service that you can inject
into your application in order to do things
like registering for push notifications, or to observe
or listen to an observable that gives you the push
notifications that comes from your application,
or understanding the lifecycle events that are
coming from a service worker. To use PWAs with Angular,
you're going to install the app angular/cliproject. I'm going to use the ng new
command with my project name. And then I'm in it flip a flag
in the CLI's configuration saying, I would like a
service worker, please. And then when you run
a production build, you're going to automatically
get service worker included in your application that's going
to cache all the static files that are generated as part of
the web pack build process. And then you can
further configure those via that
declarative file saying these are the files I'd
like to dynamically cache, these are the files you
can ignore, and so on. When you generate a
project like this, it's going to give you, again,
a short Hello World page that has all of the
necessary links to get you further started as
an Angular developer. And again, we have
the service worker. The Angular team has decided to
ship basically a single service worker that is entirely reliant
on that configuration file. So obviously, this
file exists on disk. It's generated for you,
but you can modify it to your heart's content. But it really is
focused on exposing all of the capabilities
of service worker via that file so you can do
configuration easily. There's a few other
projects that I want to mention very briefly
in the remaining time we have. There's a website
called pwa.rocks. There's a PWA builder
that you can find online. The nice thing about
the PWA builder is that it's a
web-based interface for generating manifest. You'll be able to upload
images, and it will generate all the right sizes for you. It'll generate the JSON for you. It will ask you
questions that help you understand what's going
into the web app manifest. And then it will ask
you, how do you want to generate a service worker? It'll ask you, based on the
use case that you're using, for example, are you just trying
to cache all the static assets so that the application
works offline? Or would you like
something more dynamic, where we just cache the assets
the application actually uses so that as the
user has interacted with our application, anything
that they've touched before can be accessed offline. And then also, within
the Angular project, there's a set of tools
called NG PWA tools that let you take advantage of things
like server side rendering. Lastly, let's dive
into best practices for building and
debugging these things. Remember, remember, remember
to check the Applications tab. I've heard stories of developers
restarting their browsers, uninstalling Chrome,
reformatting their machines because they can't understand
why their application isn't refreshing. So service workers are
a very powerful API, but because of the way that
they can favor performance over freshness, it can actually
break some of our expectations around the save
and refresh cycle. There's a fantastic guide
on debugging service workers by Rob Dodson. The link is bitly/debuggingsw. Another recommendation
that I would make in terms of best
practices is make sure that you're following the tools. Tools are useful because
they provide abstractions. But if those are the
wrong abstractions, you can end up
spending more time fighting the tools
because you're going against their intention. So whenever you
adopt a new tool, try and understand what the
tool is trying to do for you. Try and understand the
pieces of the workflow that it's trying to
automate because you're going to have a much better time
if you're using tools the way they intend so that as
they continue to evolve, they don't
continually break you. While the Chrome Developer
Tools are fantastic, I would highly
recommend that you don't rely on them
as the only way that you debug and
build your applications. Throttling is one of the
really cool features where I can say, hey, give me
an emulated 3G connection, or give me an
offline connection. But these tools are
sometimes not enough and won't reproduce
all of the scenarios that users run into
on a day to day basis when they're on the bus
or they're on a plane, for example. It's also important to
note that as of today-- I believe this is still true-- the offline check box does not
actually affect web sockets. And so if you're building an
application with Firebase, for example, where you're
pulling down data via those web sockets, hitting
the offline button will not allow you to test your
service worker with that data because all the data will
actually come back when you might expect it not to. One of the other
really cool techniques that's just kind of
being developed right now is the idea of having end to end
tests for your service worker. So it's possible and important
to think about how do we test and how do we understand the
state of our service worker as we're building
these applications? So there's two
projects I'd definitely recommend you check out. The first is that Pinterest
project that I talked about, where they are mocking out
the environments so that you can do things in more
of a hermetic way. But there's also work
being done to build out, for example, a PWA
harness where we can use our standard end
to end tools, where we're doing browser instrumentation
using the debugging mode, and we're actually using
UX elements on the screen to check and verify and
change the service worker status in the way that
the user could be doing. The last recommendation
I'd have is really make sure that
you're staying up to date. Service workers are
a fantastic API that are on millions, and possibly-- I think that's actually
billions of devices today-- but it's continuing
to expand and evolve as the web ecosystem
always does. A great example of
this is that we've now seen work being done in Safari
to support service workers. And so what that support looks
like, we don't actually know. But it's important to understand
and use the latest and greatest tools so that you're reaching
as many people as you can and empowering as many users
with fantastic experiences. So I'd ask you, really just
give these tools a try, and let us know what
your experiences are with them, because we all want
to make the web a better place. Thank you so much.
