[MUSIC PLAYING] BEN MORSS: Who here
in the audience has heard the
acronym PWA before? All right. About 2/3, maybe. How about AMP? OK. Very good. In the context of
Accelerated Mobile Pages, not a guitar amp, perhaps. I guess Mike and the
Mechanics were playing here a couple of days ago. They had amps back here. This is the other kind of AMP-- Accelerated Mobile Pages. And we're going to discuss
something today called PWA and AMP-- putting them together-- how this
pattern is powerful, elegant, and easy to do. And I'll show you an
example of how to do this called the shadow reader. The first question is, why? Progressive Web Apps are
these immersive, full-screen, app-like experiences on the web. And Accelerated
Mobile Pages are best known for somewhat
simpler kinds of pages, maybe for publishers,
maybe a way to get into Google's AMP
cache, and, in general, kind of a simplification of the
web for performance reasons. So how do these
things fit together and why bother with this? It's because of what I
call the web app dilemma. So let's go back
about 18 years ago. Back then, web
pages were simple. If there was any complexity,
it was on the back end. You had your pearl, maybe
some PHP making things happen, generating HTML. The front end was HTML-- just HTML, maybe some CSS,
which was brand new back then, and not a whole lot of this
little cute little language called JavaScript. And JavaScript wasn't
like a real language. It was like a toy
language back then. It was used for little things. Remember this thing over here-- you could move your
cursor over the button and it would change color. That was pretty cool. That was JavaScript. That was pretty easy. Today, it's more complicated. There's a lot to learn,
a lot of choices. You can make a very, very
full-featured front-end, web app with many, many
different frameworks, all kinds of JavaScript. It can get pretty complicated. And when it gets
complicated, there are some downsides to that. This might be you. Maybe you're spending a lot of
time learning new technologies, maintaining a
complicated app, trying to follow all your callbacks,
tracing through all the code, trying to use various tweaks to
get things to perform better. And, speaking of
performance, unfortunately, for your convenience
as a developer, the user pays a price. So notice how web apps have
gotten bigger in the last six years. They've more than
tripled in size. A lot of those things
like images, video-- but also JavaScript has
gotten very, very big. Do you have a site right
now that has 15, 20, maybe 30 JavaScript files
on it, 400k of JavaScript, maybe some large
frameworks that are loading before anything
happens, using up CPU time, using up battery power? It takes a lot these
days for a good web app. I was thinking about
this, actually, yesterday while walking
around the city. And this is the picture
I took here in Krakow. And there's music
supposed to be playing-- oh, there it is, lovely Mozart. So why are we playing
Mozart right now at a developers' conference? Because when I saw
the architecture here, it reminded me of
the movie "Amadeus." Anybody seen the movie
"Amadeus" before? "Amadeus," anybody? It's about Mozart's life. I used to be a music
professor and I showed this to my students every year
because otherwise they didn't really grasp classical music. They couldn't stand
classical music. But, Mozart-- I was thinking
about elegance and beauty and things like that. And maybe you can make it a
little quieter-- the music-- Mozart's getting
louder and louder. Elegant, beautiful
things are important. They endure. Simplicity is good. Because when things are simple,
they're more maintainable, also, for your users. Elegance also means
you have fewer bugs. In five years, your
code will still work. So simplicity actually matters. Elegance matters. And isn't one of
the goals of life making something beautiful? That's one of the goals, also,
of this PWA-AMP pattern-- helping make things beautiful
and simple and elegant again on the web. So, well, if the
web is too hard, can I make an app instead? Wouldn't that be easier? If you saw Sam's talk today, you
know that almost all the time users spend in apps is
in a few major apps-- their GMail, their
Facebook, their WhatsApp. If you're making
an app out there, the chances are very small
people will ever, ever use it or download it. Because, as Sam
was saying before, the average number
of apps a user installs in the
average month is zero. So the web is still a
pretty important thing on mobile phones and will
not go away anytime soon. So maybe make a simple website. That's not going to work. Users expect something
better these days. They want a real
web app experience. What do we do? Like a baby, we can cry. Or maybe there's an easier way-- happy baby-- is there one? There is not. OK. Thanks a lot, guys. Wait, wait, wait, wait, wait-- I've got some more
slides to show. I'm just kidding. I think the easier way
here is PWA and AMP. What is that? PWA-- you've seen before
in the talks today-- provides an app-like
experience on the web. I won't go into this in detail. You've seen this before. But things load quickly. They're engaging-- as
a good app would be. They're quick. Users aren't waiting around. They work offline. All these things people expect
from mobile phone experiences, like they're on Messaging,
like they're on some other app. They want these things
also from a website-- a fast, good experience. So what is AMP-- Accelerated Mobile Pages? People think about it
sometimes as this thing that was started for publishers. Most major publishers
in the world use AMP in some way or another. But it's more than that. It's not just for publishers. It isn't just a way to actually
make simple, live web pages, or to get into Google's
search AMP carousel, or make Google
happy in some way. It's a new pattern to
make the web easier and simpler and faster for
users and also for all of you. What is AMP? A brief summary--
it's an ecosystem for fast, beautiful,
responsive pages. As you heard earlier
today, there's over 2 billion pages on
the web that use AMP. Over a million
domains now use AMP. AMP helps enforce good
performance and good looks. It's basically a response
to the bloat on the web. It's making things
simpler, easier again. It doesn't cover all cases
but it covers most cases. Very few web pages
right now would lose that much if converted
to AMP, even though-- the first thing up there-- AMP allows you to
write no JavaScript. No JavaScript at all. So, yeah, I got a
little bit of applause. Probably some people are crying. [APPLAUSE] People are clapping. Yes, you're free, you're free. You can still use JavaScript
but not on an AMP page. It's already there. Because if you want things
that are interactive, that are easy to use,
or you want things like an image carousel where
the images slide around on the screen-- users can't stand these things
but they're very popular-- or you want a video embedded
or you want a menu-- all of these things
come with AMP. You just insert web components. So that second thing up there-- it's a superset of HTML, a
set of custom web components that do all those things
that don't come with HTML, but should. HTML was designed a long
time ago for documents, not for making
complicated web apps-- though with AMP,
you can get back to actually putting all those
things that you want into HTML. You lose some flexibility but
you gain a lot of ease of use. And you're coding less. You can code other places. And if you love CSS, I'm
sorry to tell you this-- it also restricts your
CSS to 50 k or less-- which, really, honestly,
is enough for most pages out there, probably all pages. The idea behind
all these things-- no JavaScript, web
components, and less CSS-- is to make the pages faster. So for users, AMP
pages tend to load-- even on 3G connections-- in a second, in
two seconds, which users tend to like
quite a bit, and which makes your companies money. It's good. And don't forget the
elegance thing as well. Your pages, your code,
is more beautiful. It's simpler. You're not trying to
reinvent the wheel. The wheel is already there
for you as part of AMP. It sounds kind of hard, right? I've got to learn
two new things-- PWA and AMP? I can't do that. I don't have time. Well, actually, it's not
as hard as it sounds. And to prove that, we've
created a simple example called the shadow reader. Whenever I say
"shadow," I'll say it like this
typeface over here-- the shadow reader,
because I have no shame. So let's say that you work
for a major news publisher and you've got a web
site that's out there. But the boss knows people
want to use a web app. They're sick of the web site,
sick of the slow transitions between pages. He wants a news reader app. So your assignment, from this
very, very stern looking boss over here-- you're the person
there with the hat-- is to make a web app out
of existing web pages. The site already uses AMP. So how do we do that? How do we take things
that already exist-- those AMP pages-- and get
those into a nice, immersive, Progressive Web App experience? Well, PWA slash
AMP is your answer. So why are AMPs useful in a
Progressive Web App context? Let's discuss a
couple ways AMP can be used that haven't
been used so much so far, but ways AMP is
starting to be used now which play on AMP's strengths
as web components library. So, first of all,
we'll discuss how AMP can be used as web
components, second, as rich data, and third, AMP
pages can be portable, embeddable content units that
you can embed in other pages, thanks to the magic
of Shadow DOM. I love that name-- Shadow DOM. First of all, AMP
as web components. This, actually, is
kind of obvious. AMP is really a library
of web components. Here are some examples
of those things. Here's one over here. Let's say you want to make one
of those lovely image sliders that users, again,
tend to object to, but people love these things. And there it is-- that's an entire carousel. That's done. So AMP carousel-- you must
specify width and height in AMP because the pages are
laid out in advance. So as things load and lazy load,
the pages would shift around. So all of your dimensions for
images, ads, everything else, are specified in advance. And there is a couple of
images with the AMP image tag. And you're done. There it is-- your carousel. Things lazy load. It's all good. You're done. Number two-- AMP as rich data. This is kind of a weirder idea. but kind of a cool idea
once you get the idea. Idea, idea-- that's a good word
to say several times in a row. AMP can be used as rich data. So, often, if you're
making a web app, you've got your app
shell of some sort. And you're loading
in JSON and then converting that JSON to
HTML using templates, using some sort of logic. This can be a fragile,
difficult process. So, instead of
doing that, you can use HTML itself as the data. It's a rich data source that
includes layout information, includes components. It's like a whole page layout. It's kind of like
mark down on steroids. It's this really powerful,
rich, beautiful data set. So what I mean by that-- here's a typical example. Let's say you have this
article on your web app that you're making
over here and there are some [INAUDIBLE] ancient
babies I've heard of that, apparently, aren't very good. And you have an article
about that-- usual data sources, data whatever. Here is how it might look
on the bottom over here. Maybe you have an
image of a guitar. Maybe you've got an H2, a link. Maybe you've got an ad in there. This is like data. So you can pull this
in to your web app-- which goes along with the
idea that AMP can be portable, embeddable content units. So you can grab some part
of the page which is AMP and stick it into your
Progressive Web App. So, again, taking an AMP
page or some AMP stuff and using that in a
different application. So you can actually take your
web pages already that exist and cram those things
into a web app. And here you are, with your
hat, thinking, oh, this is the key to my
project over here. I don't have much time. I can use this pattern,
taking our existing AMP pages and putting those into
my new, immersive PWA. But how? The first key to this is
the magic of Shadow DOM. So Shadow DOM is simple and
kind of cool and magical. It's simply a DOM
sub-tree that's fully encapsulated
inside an HTML element. All the HTML, all
the CSS, is living inside an element in the DOM-- Shadow DOM. It's part of the
web components idea. And AMP comes in a version
called Shadow AMP, which allows an entirely valid
Accelerated Mobile Page to exist inside another page. This allows you to AMP just one
subsection of a web page, which we're going to need in our
app we're making today. How does this work? On the top over
there you see we're loading up not the usual AMP
library, but the Shadow AMP library. And then, on the bottom, you
see, we're going to actually-- once AMP exists-- we're
going to just attachShadowDoc over there, three
arguments, the container where the shadow root should
be, the document itself, and the URL from which the
document came originally. The complicated thing here is
this is loaded asynchronously. So you can't attach ShadowDoc
until it's actually loaded. So we use this asynchronous,
callback pattern to do that. You see, in the middle, that
function means if I [INAUDIBLE] AMP ready, which
takes the callback. And, simply, it looks
for a global called AMP. If that global already
exists, it adds that callback to an array of callbacks. If it doesn't exist, it
defines that as empty array. So this way, as AMP
is still loading, you can keep on attaching
callbacks to this object. When AMP actually loads up,
it then finds these callbacks, and then it runs everything. It may sound complicated,
but it actually isn't that complicated. I'll say it again more
simply with fewer words-- you load the Shadow
AMP asynchronously. Once it's loaded,
you can then use the attachedShadowDoc method
to actually attach your AMP document somewhere
inside an existing page. Let's take a look at
this now because it's getting pretty abstract. Let's go over to
demo over here and-- interesting-- my computer
logged out during this time. There it is. It's back. So this is the Shadow Reader. Here it is. In this case, it uses "The
Guardian" as data backend. All the news here is
kind of depressing today so I apologize for that. There's two modes for this. This is the cards mode. So this just shows top
stories from "The Guardian" as a series of cards. And then clicking into a card-- I'll look for one that's
not bad and scary. Here we go. A black hole--
that's kind of cool. It's not scary yet. Clicking on that, you
see a bit of an animation and it pops out. And there is the article
mode, the second mode of this application. There it is-- an
enormous black hole, not a problem for a long time
as far as we can tell. And, by the way, this bottom
over here is all the AMP page. That's all AMP. If you go back over
here, you're back here. There are sections and so on. If you look at this here,
we can see in HTML-- which is very small,
unfortunately-- if you can see this,
at the very bottom there's a thing called
article over here. And somewhere in there,
if you can see it, this is called Shadow Root. And in there is an entire AMP
page just hiding in there. And there's the
body, all the content there on the Shadow Root. I know this is very hard to see. But try it out. AMP.cards is out there. It's public. You can use it. Check this out-- the
code is out there, too. Check it out. See how it's built. Let's
get back to the slides now. We're going to talk more
about how this thing is built. How is this thing built? As we had discussed
already before, there is your AMP page
living within the PWA. That's the real key. And three things happen-- the first thing is
that AMP content gets pulled in from an RSS feed. And then we inject the AMP
HTML right into the DOM. And then around all that, is
a lovely Progressive Web App, making this nice,
immersive experience we're talking about here. Here's the first step-- not that complicated--
you pull the AMP content in from the feed. And you can see
here, we actually use the good old SHR over here. Because you can use fetch,
but the advantage of SHR is that the response to XML
is actually a parsed DOM. So once you get
this back, you've got a whole document object. You can just tick that right
into the DOM of the main page. This is very convenient. And we're going to
remove parts we're not going to use over here. So, notice on the
top, for example, "The Guardian" has this header. We don't want to see that as
part of this app experience. You just remove things from
the DOM you don't want. You can take out sidebars,
take out headers, just to get the part
they actually need. Step two, we inject the
AMP HTML into the DOM-- not that complicated. We create a Shadow Root and use
that magical attachShadowDoc to actually, again,
take that AMP document and stick it right there
into the Shadow DOM. And then, all around that, is
a nice Progressive Web App, which has the kind of features
you want from Progressive Web Apps. It loads quickly
with an app shell. As the app moves around, as
you navigate through the app, things go on loading quickly. The experience is
immersive throughout, like an app would be. You have the
possibility on Android adding to the home screen
and an app-like display, taking away the whole URL bar. And content is
available also offline. How do those things work? Quickly, the first
thing over here is that the initial
load is pretty simple. Let me show you
over here again-- if I can get back to
the computer here-- the actual, original payload
over here that comes with this. A lot of CSS. The HTML is pretty simple. A couple of things here. And then, notice as
we go along here-- let's see if I can zoom
there a little bit-- you see these little
tildes over there. See those things? If you use Facebook, for
example, and you've seen, when you're loading your
feed, those little things appear with rectangles
that kind of resemble actual things in
your feed, but they aren't things in your feed. They're just actually
an animation. So it gives the user the
impression things are loading, when they're actually not
really there quite yet. Users like that, if things
are partially loaded and they get to see
it kind of load. This is like that,
but just pure text. So before any
images load at all-- anything loads at all-- you've
got something there that kind of resembles how the
app's going to look, a set of lovely tildes. Let's go back now to
the slides, please. Thank you very much. So, yeah, simple
initial load over there. And that thing at
the top over there is so I can tell whether it's
actually from the URL in cards mode or article mode, and apply
the right kind of UI skeleton so you have that nice kind
of loading in the beginning. And then, of course,
as the app moves along, things load fast because
you've AMP pages. AMP pages load very fast. They're very simple. And you use Shadow DOM to get
those things into your PWA. Then the immersive experience
is pretty easy to do. I'm going to go back to the
demo here one last time. We can see these lovely
animations over here. Again, this is just
a normal web app so you can make
nice things happen. You click on this
black hole over here. It animates upwards nicely. And you change articles. Things merge around smoothly. There's also stuff
here for accessibility, for screen readers,
all of those things were easy to do because you've
got all the power of PWAs and CSS and all those things. Again, try it out yourselves
at home if you'd like to. Let's get back to
the slides over here. And this part is
easy for the PWA. You've got a manifest. For Android, those icons
over there let you add things to the screen-- the
home screen, that is-- and then, display
standalone just tells Android to display the
app in a full, immersive app experience. And this part is super simple. Finally, offline content. This can be a little challenging
when you do service worker. The cache thing may be a little
bit complicated sometimes and involve some coding, some
promises, things like that. But, in this case,
it was very simple. We use Workbox as a bit of
a work-around over here. I recommend trying out
Workbox.js, a great service worker library. And this, by the way,
is the only library that was used in the making
of this whole web app. There is no angular, no
react, not even jQuery. The code here is incredibly
small to make this happen. And, in fact,
minimize is about 10 k of JavaScript behind the scenes. That's it-- about 10 k. Workbox makes
things very simple. Over here is the code to
cache our lovely yql queries. That's all you do. Register your route,
declare your strategy, and you're all done. The service worker stuff here
is maybe 30 lines of code. So there is offline content. We also pre-cached some things
like images, other things that are important for the app. And like I was just
saying a minute ago, there was no framework used
in the making of this app, not even jQuery. I mean, these things over here
are samples from the code. They're a little bit
ponderous in some cases-- document.doc.queryselector,
remove attribute, all these things. JQuery makes it
a little simpler, but this is just to show we
didn't need jQuery for this. You still have
pretty small code. It's pretty simple. It's just JavaScript--
but not much JavaScript-- a little bit like the old days. So this is good. You made the web app. The boss likes you. You can keep your job-- triumph, happiness,
all those things. So you're happy. Than you think-- great,
I made this awesome PWA. But is this AMP, though? I thought this AMP
thing is important because I have to get
into Google's search carousel and the AMP
cache and all those things and make Google
happy in some way. But this is not
an AMP over here. I've made this normal web page. So is that OK? Can I do that? And, yes, you can. Who cares? Go ahead and do it. In this case, the main app
would not pass AMP validation. It isn't supposed to. But it's fast. It uses AMP and just
works really, really well. If you want to actually
get into Google AMP cache on the first page
of your application, there's a pattern for that. The first page can
also be an AMP. The entry page-- landing
page-- can be AMP. Actually, AMP has an install
service worker component. You can use install
service worker to get your PWA started
behind the scenes. They can navigate to the
next page, which is the PWA, and then you can use
AMP within that again. So, again, you can use
these things in various ways to get all the benefits of AMP-- to get the pre-rendering
and all those things that come from the magic of finding
your link in Google Search or elsewhere that
has an AMP cache. And then the PWA starts up. You can use AMP components in
there to make your life easier And it's more than
just publishing. The same pattern applies in
more, other kinds of ways. What if you've got a site that's
like a leadgen site, where users are filling
out this long form-- one of those things with
five different screens, your name, your address, your
birthday, your neighbors name, your dog's name,
your cat's name, the name of the tree
in your front yard, all of those kinds of things. This happens sometimes. It can be hard for users. If you use AMP, AMP comes with
nice, validated form fields. So it makes your life easier. And, like with the
articles just back there, imagine instead of
articles, imagine pages of the form in a PWA. So you control the experience. Users can't stand it when
they're working on a long form and they go to the next page
and they face a long load. They abandon in those cases. In a PWA, things can
load more quickly, especially if they're AMP. You can go back and forth,
you can control the screen, make it fun for the user
to fill out this long form. Register now. Another idea-- e-commerce. E-commerce is a new thing
that's happening with AMP. Various e-commerce sites are
now using AMP for all kinds of things-- product pages, listing
pages, up to and now also including the
checkout process, is just now possible
also with AMP, thanks to the
payment request API. So, in this case over
here, I imagine instead of your news articles, a
series of product pages, which are all written
with AMP so they're fast. The user isn't waiting around
to actually have things load. And dynamic content is
possible with AMP as well. There's AMP state. There's AMP lists. There's various components that
let you actually change things on the screen dynamically. So you change the number
of things you're buying, the prices can
change, shipping costs can change with user input,
and so on and so forth. Or imagine the
travel application. Instead of these articles,
you've got hotels-- hotel information-- and
you go back between hotels. So, again, all possible
with AMP in a PWA context. The upshot is this
makes you money. Because the users are happy,
because they have a better experience, they're not
abandoning the pages as much. And a lot of data
shows us, AMP pages tend to get better
user engagement. A lot of data shows
us that faster pages get better user engagement,
get better conversions, lower bounce. So your users are staying
on for longer on your app and they're converting--
they're buying something or they're viewing an
ad, whatever it is. Ad support in AMP is also
very, very advanced these days. So you gain money
from the users. And you also make money
because developers are spending less time working on their app. Things are simpler for them. So you can make things more
quickly so you make money on both sides of the coin-- which, of course,
isn't your motivation because you're programmers. You don't care about the money. You care about the
beauty of your code, the integrity of your work. Money is just kind of one of
those things that gets you rent and maybe occasional
Doritos and ramen soup-- or I guess kielbasa and
dumplings over here. But, also, don't forget that-- oh, we went backwards
instead of forwards-- don't forget, also,
that this is better for you, the programmer--
not just because of the money you're making now and you're
retiring early or becoming a manager or something--
but because you didn't just create this terrible,
Frankenstein web app that was a hodgepodge of
various JavaScript you found on the internet
and kind of copied things and pasted them together. You don't have to panic. This was something else I
found in old town as well. Instead, you have this lovely,
maintainable, elegant code that's going to work
for longer, that people will like in a couple of years. Future programmers at your
company will see your code and they will smile,
instead of thinking, why did you make all this stuff? This is crazy. They'll see it. It looks easy. It's elegant and maintainable. And, in conclusion,
isn't life that creating something beautiful? This is your chance to do that-- PWA and AMP. Thank you very much. [APPLAUSE] [MUSIC PLAYING]
