[MUSIC PLAYING] ROWAN MEREWOOD: Good afternoon. Welcome to Frameworks and
Tools for Progressive Web Apps. My name is Rowan Merewood. I'm a developer advocate
for Chrome and Web. I've come over
from London today, so the weather is making
me feel very welcome. Thank you for that. I'm also here for the
rest of the event, so this is quite a short slot. But I would love to carry on
this conversation with you. If you can't find
me in person, you can also find me on
Twitter, rowan_m there, so please feel free
to ask me questions. Now, what I would
like to do today is explain the state
of PWA tooling to you, explain some of the
goals and the philosophy behind that tooling so you have
a sort of concept of why you're using it, talk a bit about
how you can apply this in single page
applications, and finally, give you some best
practices as well. Now, just so I have
a bit of an idea of who's been paying attention
and who's still awake, who has already
heard the term PWA? Good, that should be
nearly all of you, even the Android developers,
because it was in the keynote this morning. What I would like to do
is give you some context before we go into this. One of the questions
that we always get is, well, what is the
right way to build my app? How do I build the perfect PWA? Please don't ask
me this question, because of course, the
answer is it depends, right? We're all coming from
different situations. Some of us have apps already. Some of us are building
brand new apps. And also, the approach differs
for different verticals as well. So the approach you take
on an e-commerce site is very different
to the approach that you take on a media site. That said, there are
some common themes that run through this
that we have identified. And we've tried to distill it
down into four main pillars that I really want you to think
about when you're busy building these experiences. First of all, it
needs to be fast. You've probably
heard the message because we've repeated
this multiple times, but every microsecond
of time that you make the user wait,
that's a user who's abandoning your site. That's a conversion
that you're not getting. So you really need to
focus on making sure that the experience is
as quick as possible. Now secondly, because we're
talking about Progressive Web Apps, we're really talking
about these high powered websites, the websites that
have taken the right vitamins. But that means that we've
raised our users' expectations, so they're going
to need to be more integrated with the device. That means there's
an expectation that I'll have access to the
full control of the camera. I might have access
to Bluetooth. I expect location to work. I expect my device's
orientation sensors to work. And again, as these experiences
become more app-like, that also means that
users are going to have more app-like expectations. And that means reliability. These sites need to work
regardless of the network connection. I always should get some kind of
experience that is useful to me as a user. And finally, like Sam
mentioned this morning, no matter how many of the
magical bells and whistles you implement, none of
that makes a difference if you don't have the engaging
content and functionality underneath that. So with that in mind, let's
take a look at some of the tools that we can use and how
they go about helping you. And the reason I want to do this
is because what we want to do is put the user first. We want to create the best
user experience on the web. And we feel that to create
the best user experience, we should also give
you the best developer experience so that it's easy
to create these experiences. OK, I'm going to show
you some tools in a bit, but I want to tell
you about what those tools are going to be
able to help you with first. Top of the list, like I
said, putting the user first. Save the users
time, because time is the biggest investment
that the user is making into your app. So you can use tools
to start identifying those areas of poor performance
and apply common patterns to make those time
savings and speed up the performance of your app. Critical to this,
and closely tied, is also bandwidth,
because bandwidth is spending the time of the
user downloading the app, but it's also directly
spending their money as well. So make sure that when you're
analyzing your bandwidth use, you're taking a respectful
approach to the user's budget. And then one of the
things that has always been heartening about
the web is this idea that it's completely open
and accessible everywhere. I make a web page, and when
I publish that, any client, any browser can
access that web page. But in reality, we know
that's not quite the case. You need to make tweaks
for the different browsers, different things are supported
in different locations. But that shouldn't be
directly your problem. Again, that's
something that you want to make use of
tooling and libraries to handle the differences
between those browsers so that you can focus
on writing the code that solves your business
problems rather than starts to try and deal with
platform inconsistencies. And when I talked about
integration before, we enable things like
push notifications on the web across
browsers, across systems. But there's a lot of
multiple moving parts that you need to deal
with to make those push notifications happen. But again, it's all standard,
so tools and libraries can help you there. I want to touch
on code generation and how that differs from
just using a library. And finally, I'll show
you some of the tools that you can use to make
sure that when you've gone through all of
these previous processes, you're still enforcing the
best practices that you start with a good experience and you
keep a good experience as well. Let's look at some of the
technology behind the PWAs that these tools are
going to help you build. So first of all,
a PWA is normally identified by its manifest. So this is a simple
file that you can think of as the
public description of what your PWA is capable of doing. Then there's the service worker. The service worker is
the piece of JavaScript that is able to run
in the background and take care of things for
you when your site is not present in the browser. And finally, we're going
to use some of these tools to actually build great
applications as well, which is hopefully what you're
all interested in. OK, starting with
the manifest then. Since it's a
standardized JSON file, there are a few
tools that you can jump into that are, A, going to
help you generate file and go through the various items. And they will automate
some of the tedious tasks in there, like providing
the multiple sizes of icons and marking them up correctly. But it's also going to
help you make decisions about what kind of
things you may want to include in your manifest. So you've probably seen that
you can specify that your web app is a standalone web app. You may want to investigate the
different display modes, what that means for browser support,
what that means for the user experience. Again, going through
these tools will help you understand the
full range of options that are out there
and why you might want to choose particular ones. The service worker,
then, falls kind of into the other category. It is an incredibly
powerful tool, but with this power also
comes a lot of complexity. So as you can see
here, this is just the lifecycle of
the service worker when it is being
added to your page. So it can sit there
as a proxy handling all inbound and outbound
requests from your page. It's going to be what handles
the incoming push requests. It can also coordinate
across all the open clients you currently have
on a device to manage the communication between them. This kind of low level
power is incredibly useful, but there's a lot that you
need to learn to really take advantage of that. So again, we can wrap all
of that functionality up in a library and
some code generation to make sure that this is
nice and simple for you. I wanted to show
a bit about what you can do with service worker. So file caching--
you'll see that there are a number of
different approaches you can take to doing that. You can either do
your file caching on or during the installation
of the service worker. So this is when you might
choose to proactively fetch a number of resources
that you need to make your site available
in an offline mode. But you might also want
to do this at runtime, because obviously, it
would not be a good idea to spider your entire
site and download it to the user's device. So you may just want to fetch
whilst users are browsing your site, cache the content
that they're looking at, and store that in
the service worker. And finally, there are far more
advanced caching strategies that might be relevant to your
particular business use case. For example, maybe you have
a special offer on the site that you want to ensure
is available for the user, but it has a hard
expiration time, so you don't want to show
it past a particular point. Push notifications,
then, like I mentioned, there are a lot of
standard parts here. You want to do
different behavior. When the push
notification is received, does the user currently have
your app open or is it closed? If it's open, you probably
want to do something different by showing an in-app
notification versus showing a notification on screen that
the user will tap and navigate through to your app. And finally, on code
generation, then, really what I would like you
to understand here is that code generation
is a way of giving you code that is hopefully
fast by default. It's hopefully great
by default. And comes with a selection of industry
best practices built in. So it should have integration
for metrics built in there, integration for analytics,
security, usability, and so on. But the distinction between
a code generation tool and a library is that when the
code generation is complete, that code is yours. You need to make sure that
you understand the code that has been produced
and that you take it through the same review
and testing processes as you would for code that
any of your developers have written. So code generation
can be a lot of fun, but don't assume that it's
some kind of magic wand that you can just spread
over your application and everything will work. OK, I want to split
the tools for building a PWA into a couple
different categories. Generic tools which we can apply
almost anywhere; some framework specific tools
that I'll show you; and then all the way
at the end of this line is, once you
understand these tools, you start customizing them to
be tightly coupled to your own build and application process. If we're talking
about generic tools, then, the best place to
start is with the browser, because you are as close
to your user as possible. Now, Chrome has its
own developer tools built into the browser. And we could spend an entire
session exploring this, but I want to highlight
two areas that are particularly important if
you're working with Progressive Web Apps. The first is the
Application tab, and specifically, the service
worker entry inside of that. If you go into this when you
are looking at any web page, you can see the currently
active service workers that are attached to that page. You can see what
stage that they're in. You can examine what
they're storing. You can look at the console log
specifically for that service worker as well. As part of your
development process, you're going to want to be
very familiar with this, because as you start to
introduce all of this caching functionality, that means you're
also going to need to make sure that you always know when
you are getting the latest version of the code. You can also see and
hear that there's a method to bypass for network. So when you're developing,
you can always just make sure that the caching for
your service worker is completely ignored and you're
always fetching from disk. Now secondly, who's already
visited the Lighthouse booth? Yeah. Everyone else, after
this, you should go see the Lighthouse booth,
put your site in, see what kind of score that you get out. Now, Lighthouse is
a standalone tool, but it exists inside of Chrome
DevTools as one of the audits that you can run
against your site. So again, if you go to the
Audit tab inside of DevTools and perform an audit,
then you will get back a score that covers the
various Progressive Web App functionality for your site. It makes a number of performance
related measurements, accessibility
measurements, and also a number of general best
practices for websites as well. Hopefully, already, you've
heard from some of my colleagues about Workbox. So Workbox falls into
the generic tool section, because what Workbox
focuses on is how it can build out a
service worker for you with a number of
specific patterns. That means it's actually
relatively simple to take Workbox and apply
it into an existing site, or apply it to a
new site as well. It gives you three main
things, but the team is always working on
bringing additional best practices into this. First of all, various
offline caching patterns. So when I talked about
the various approaches you might want to take, Workbox
provides these by default. You can do cache first. You can do network first. You can race the two
so that you can respond with whichever is quicker. You can set expiration
policies and so on. It also makes available
offline analytics too. This means that when
your app is offline, you can still collect
the analytics events. And when you're back
and connected again, then it will batch those
together and send those on. So this is incredibly
important, because if you make your app available
offline, you still want to know how your users
are interacting with it so you can improve it in the future. And finally, we make use
of newer technologies like background sync as well. So this means that you have a
number of built-in strategies for how you want to
refresh content that you're storing on the user's device. Workbox is open source, so you
can come find this on GitHub. If things aren't
working out for you, then please raise
issues, talk to the team, or if you have
something that you think Workbox should
be able to do, you could even contribute
some code yourself. Now, we're not the
only people doing this. If you make use of webpack for
bundling or other parts of your build pipeline,
then I would highly recommend looking at the
offline plugin for webpack. This does a number
of similar things, where it enables you to build
out a service worker based on your webpack configuration,
where you can specify various assets for
caching ahead of time, or caching when the
user browses to them, or just optimistically
making them optional so that you can cache them
when they're most useful. Again, this is an
GitHub, and there's plenty of sample code and
documentation linked off of that repository to
help you get started. And the other
thing, like I said, I really love the open nature
of the web and how easy that makes it for
everyone to get involved. So I also like it
when companies then start contributing this
stuff back as well. Pinterest has been
doing a huge amount in terms of building a very
highly performing web app. And they have actually
started pushing back some of their libraries
on creating, testing, and experimenting
with service workers. One of the things
that's particularly interesting about
their offering is they include a number of test
sort of harnesses and isolation methods for the
service worker as well. So we sometimes have a
tendency with new technology to get a little
carried away with all of the cool stuff we can build
and not necessarily cover testing it. So to me, this is really
a sign that the technology is becoming much more mature
and production ready as well. And then, because of
how fast paced this is, I feel it's also important to
understand some of the history as well. So some of the earlier libraries
that are still active, there's sw-precache and sw-toolbox. Toolbox Now, these have
been superseded by Workbox. Because they were earlier,
they're a bit more tightly coupled to specific
functionality. But what you'll find is that
a number of the CLI tools that I show you
for the frameworks are actually making use of these
libraries in the background. So they're worth looking at,
but I would look at Workbox first if you are starting off
something new of your own. OK, it's also
always good to have an industry convention
or a benchmark that you can use as well. So most of the time, like if
you have a device with a screen, whether it's like a graphing
calculator or a printer or an oscilloscope, the
default sort of benchmark is to see if you can run
"Doom" or "Quake" on it. So for front-end
developers, it's, can I take your
JavaScript framework and write a hack and
use client with it? So HNPWA is a collection
of hacker newsreaders built in a variety of frameworks
using a variety of libraries. And what I find really
useful is that this is a way to compare approaches
in the different frameworks. So if you're trying to
decide which one you want to choose to solve a
particular problem, or you want to see how
the industry is making use of different
technologies, then this is kind of a great
playground to go and compare solutions to the same problem
across a multitude of tools. OK, hopefully by
now you should have a feeling for the
kind of mindset that I'm hoping that
you can get into. What I would like to
accomplish with this, and what you should be thinking
of these tools as doing for you is, one, simplifying
your mental model. The amount you need to learn to
properly understand and become an expert in service
worker is huge. And that investment is
probably not part of the time that you want to be using
when you're doing your job. And also, a lot
of these problems have already been solved. So there's no need for
you to reinvent the wheel and spend a lot of time
writing a lot of extra code to handle all of
these edge cases. So all in all, this is
about saving time for you and basically getting the
best solution for your user. And really, what it
means is that you can focus your effort on the
use cases that are important. The problems that are
closer to your business, not the problems that are
closer to the platform. And as well, like I keep
saying, the accessibility and the open nature
of the web means that it was really easy
for me to get involved when I was younger, creating
terrible websites with Perl backends, but it was
still very simple. It was accessible. So what this means is that
by using these libraries, you can still layer
in service worker with that same
level of simplicity and just get going and get
something published on the web. And when I talk about
edge cases as well, like the kind of things that
these libraries will handle for you that you don't want
to have to try and write again yourself, service
worker installation. If your app loses connectivity
during the install, then what are you going to do? A naive approach
here would be to say, well, I had a list of
things I was going to cache, so I just won't cache them. Or maybe you actually
say, I didn't complete caching my list of things,
so I'm going to delete it and I'm going to try
downloading it all over again. Neither of these are good
solutions for the user. One of them gets them nothing. The other one makes them
spend their bandwidth again to get the same
result they could have had. If you use a library
here, there are a number of approaches that can
actually go through, validate the existing items that you
have cached, and then pick up and resume the download
when you left off. And again, what if your
user has full connectivity? And by this, this seems a
little counter-intuitive, but what I mean here is if I'm
reading a piece of content, and I'm getting the cached
version from your service worker, and then it
updates in the background, what should you do? Should you force me
to refresh my page? Should you show me a
little notification saying I can tap here to refresh? Or can you actually
get the content and dynamically insert it
into the existing page? All of these patterns
already start to exist in these libraries. So rather than trying to work
out how you're going to do it, you can just work out
which one you want to use. And finally, one of the
benefits of service worker and having an additional
caching layer here as well is that if you're
dealing with an API that you don't control,
you now have the ability to add additional layers
of caching on top of that. This means that if
you have an API that isn't going to
work while offline, you can actually cache
the responses from the API so that when your
app is offline, you can still act as if you're
getting the last piece of data that was available from the API. OK, now I'm
reiterating this again. You're here to save time. You're here to save
yourself a lot of code. It's not just developer
time, it's operational time, it's bug fixing, it's QA. And save a lot of effort. The reason I reiterate this is
because of the number of times that developers always seem
to want to go off and reinvent the entire universe because
it gives them an opportunity to write a new
JavaScript framework. Please don't do that. Now I want to jump in to
single page applications. I also want to stress
here that there are lots of different
ways of approaching PWAs. As you've probably
seen, my colleagues have shown you a couple. Tomorrow there's a talk
on migrating your existing site to a PWA as well. But if you are starting with one
of the single page application frameworks, then this is a
selection for you to do so. Now, this is by no means
a comprehensive list. Like I was warning, in the
time that I've been presenting, someone has probably written
and released a new JavaScript framework anyway. Maybe someone in this room
has done this, actually. But what I will
do is I will show you examples from these five. Because what I
would like to stress is how easy it is for you
to just dip in and get started so that you can see
how these frameworks operate and you can start to make a more
informed decision about what you would like to
choose for your project. Let's start with React then. So React has create-react-app. And this is a
command line script that is going to create
a service worker for you. It's going to generate
your web app manifest. And it's actually
going to give you a cache first strategy for
serving your assets as well. And it's as simple as this. I'm using YARN in
these examples, but there's no reason you can't
use NPM, or your own package management, or manually
downloading these as well. So here I'm installing
the create-react-app into the global scope
so it's available for me on the command line. I'm then calling
create-react-app with just the name of the app. I jump into the directory
and I run yarn build. At the end of this, it's going
to output some information for you saying how you can run
a development server, how you can run a production server. Run that production
server and jump in, and you'll reach
the Welcome to React page where they're
actually just going to show you where in
the code directory you can go to continue
your adventure. If you open DevTools
as well, this is an ideal time to go and
look at the service worker that has been installed for you. So you can take a look in there
and you can see the methodology that they're using to create
that cache first approach to serving the content. Next up is Preact. So this is the Preact CLI. This is a slightly more
fuller featured by default. They give the app
creation to you. And what they put out in
their default template is actually an app shell. So you get your
static index HTML with some content pre-rendered. And then it's going to go
and fetch the first route. Preact also provides
browser list autoprefixing. What this means is
that, by default, you are going to get
customized versions for the different browsers
that are coming in. And quite interestingly,
this is one where you may want to
look at this regardless of if you are using Preact. They have a configuration
that will interface with Firebase static hosting,
because Firebase static hosting is HTTP/2 and can
handle server push. So their configuration,
by default, will actually take
advantage of HTTP push to push some of
those resources down, speeding up that delivery
to the user even more. Like I mentioned before,
they use sw-precache in the background. So if you want to understand
what they're doing, it may be useful for you to
look at that library too. And again, we're just
adding the Preact CLI. In this case, we're
saying create default. So default here is the
name of the template. There are a number of
different templates that you can explore if you
want to create different apps. I do that. I jump in. I run yarn build. I get my feedback back for how
to run the development server. And I jump in. And by default, they
actually give you a bit of a material design
style app, where you're actually seeing the routing
component in action as well. So the navigation that
you have at the top there will enable you to navigate
between different tabs. We've then got the Polymer
CLI for the Polymer framework. This gives you, again,
manifest generation and an optional service
worker you can drop in. Some approaches
that Polymer takes that are quite interesting,
they actually, by default, give you three
different bundles. They give you an ES5 bundle,
an ES6 bundle, and then they also give you an
unbundled ES6 version. Now, as browsers
are progressing, people are starting
to experiment with, should we, do we still need to
bundle our JavaScript or can we leave it unbundled? At the moment, you probably
still want to bundle, but this is a good way
of immediately getting that unbundled one so
that you can benchmark between the two of them to
see what the performance difference is for you. Polymer CLI also gives
you an implementation of the PRPL pattern
out of the box. So there is a server that
comes with the Polymer CLI that you can use to serve
your content using HTTP/2 push and actually proactively
pushing a number of resources to the user. Again, we're pulling in
Polymer CLI in Bower. We're making our directory. We're jumping in. We're running Polymer in it. Now, this will take you
through an interactive process where you can select the
number of starter projects. I've chosen the
starter kit here. Then I'm running build. And we get another
nice material design related app with navigation
and routing built in. Again, go and take a
look at the service worker that's being run there. That will show you
not just the caching, but also how it handles some
of those incoming resources as well. Vue JS-- so in this case, we're
going to go get the CLI tool and we're also
going to pull down a number of default templates. This gives us the app creation,
manifest, the service worker, the app shell. One of the things that
Vue does is it actually does some nice lazy loading for
the additional JavaScript, CSS, your fonts, and so on. So I would recommend
looking at what they do there to
understand how you can pull in that functionality
as you need it, rather than necessarily
bundling it all up front and pushing it down to the user. That looks like this. We're adding in our Vue CLI. We're initializing the project. This is another interactive
one, so it will guide you through the process. And it actually gives
you some helpful hints on how to name your
application so it's not truncated and so on. We go in. We build the yarn application. And then we jump straight into
our Vue application again. And as per usual, go take a
look at the developer tools. And there's your service worker. And then finally, we can
take a look at Angular. So Angular CLI tool will also
give us the app creation, service worker. What they do with the service
worker is a little different. So rather than giving you
the service worker directly, they actually have a
JSON-based configuration file that is designed to handle
the standard caching. There's a plugin you
can pull in for handling pushing notifications and
other lifecycle events. So they've kind of tried
to provide this abstraction on top of the lifecycle
so that you can just focus on the processes that
you are trying to implement, rather than needing to
necessarily understand the service worker itself. Inside of here, I'm
adding Angular again. I'm running the NG
tool to create this. And inside of Angular, what
you actually need to do is set a few
configuration options here to say that I want a
service worker by default. And then I make the production
build of my Angular app. And we jump in. And we've got a basic Hello
World app with some links off to other applications
that can help get us started. OK, that is my
whirlwind tour through some front-end frameworks. You're all experts
now, so go off and build the next
generation of PWAs. But I wanted to highlight
a few other projects that you can look at. PWA Rocks and PWA
Builder are actually very good tools for
taking you through some of the functionality choices
that you want to make. So PWA Builder gives you
this kind of radio selection that you can go through,
answer questions about the kind of functionality
you want, and it will start to spit out
some basic templates and starter kits for you. Best practices, then,
to finish this off. Always remember to go and
check the Application tab, because I guarantee you will
run into a couple issues the first time you are
using service worker. Rob Dodson has actually written
an excellent guide that you can get to here, bit.ly/debugging
dash service worker. This will give you a number
of tips on doing things like adding a kill switch
to your service worker so you have a sort of
escape hatch to wipe it, making sure that you know
the correct way to reset this inside of DevTools so
that you're not consistently clearing your entire
cache and cookies, maybe uninstalling and
re-installing Chrome in the hope that
you can actually get a fresh version
of your application. And really, the piece
of advice that I would like you to
leave with here is try and follow the tools. So if you find yourself fighting
with the way the tool is trying to do something, then
that's probably a sign that either you need to
change the way you're thinking or you need to look
at a different tool. So the tool should be getting
you 80% of the way there. And it's that
remaining 20% that you want to be focusing your effort
on, not fighting with the way that the tool is
doing the generation. And a couple other caveats. Amazing as DevTools
is, please don't assume that it is a
be all and end all. There are a couple
of things that will not work exactly as you
expect inside of DevTools. For example, the
offline checkbox that you use there doesn't
affect every single type of network connection. So if you have web sockets,
say via the Firebase Realtime Database, that data may still be
going back and forth even when you're in offline mode. So when it gets
through to the end, always make sure that you test
on a real device, preferably the same device that the
majority of your users have. I also want to just call
back to the Pinterest stuff, because they also add in the
end-to-end tests for service worker as well, which
can be incredibly helpful for isolating that
logic and testing it through. And then, really,
the last thing is to stay up-to-date
and stay involved, because service
worker is gaining a huge amount of adoption. So Safari is going to be
implementing it and so on. But it is in development and the
spec is always being updated, so that means you want to watch
for those future developments. And if you have a direction
that you would really like to project to go,
then this is the time to make your voice heard. So please go out and
give those tools a try. Give feedback on
how you found them. And I would like to say thank
you very much for your time. Any other questions, come
find me or poke me on Twitter. And please enjoy the
rest of the event. [MUSIC PLAYING]
