The Hitchhikers Guide to Progressive Web Apps

• Douglas Adams
• The World Wide Web (www)
• The First Website
• The First Multi-OS Browser
• Flash Sites
• Apple iPhone
• Responsive Web Design
• Progressive Web App - Frances Berriman
• 2019 the Conservative Party Conference App
• WWW is the Biggest Platform
• Data is a critical
• Every Step costs you 20%
• Almost no one uses an app
• SVG
• CSS Animation
• Service Worker Cookbook
• Web App Manifest example
• Financial Times Web App
• Pintrest PWA
• Uber PWA India

Hello everybody.

Sorry about everything.

I'm a bit stressed.

But welcome to my talk.

My talk is called The Hitchhiker's Guide to Progressive Web Apps.

I wrote this talk quite a few years ago.

I wasn't expected to be speaking here today.

But I've looked through it and I think it's all still relevant.

Of course it's still relevant.

It's the web.

So let's see where we can go.

So things I'm going to talk about today.

First of all I'm going to give you a short history lesson about the web and how it's going to continue to win no matter what JavaScript libraries are thrown at it.

Trust me.

The web will continue to win.

I'm going to talk about what are Progressive Web Apps.

I'm going to talk about why you should use Progressive Web Apps even though Apple is fighting against us and you'll know about that from coming to State of the Browser over the past couple of years.

We've had numerous talks about that.

I'm going to talk about the technology behind Progressive Web Apps and what that is.

And then I'll show you some examples, some really good examples of Progressive Web Apps out there in the world.

So let's start.

Before we start, very quick history lesson.

So at half past 10 on Wednesday 8th of March 1978, yes I was alive, Douglas Adams introduced the world to the iPhone and Wikipedia and he called it the Hitchhiker's Guide to the Galaxy.

The problem being when those companies came along they didn't use his name.

They should have just jumped on it and everybody would have been on board straight away from day one rather than that slow build.

Anyway, March 1989, Tim Berners-Lee made a proposal with all of these little diagrams pointing and basically he was saying I think documents should link to each other and his boss said vague but exciting.

This is so exciting that 4 weeks today I'm going to the place that this happened and I'm very excited.

It's beyond anyway.

I might talk about that in the future.

Last week in Brighton, two people that we respect in our industry, Jeremy and Remy gave a talk about when they went to CERN to rebuild this thing.

So the World Wide Web was the very first website.

It was just some text and it had some blue links.

It was just HTML.

There was no JavaScript, there was no CSS in those days.

It was just HTML.

In fact it didn't even have things like image tags and things like that.

It was very, very basic.

But it still works.

That's the same website, the code has not been changed and it works today.

That website was accessible and it was responsive out of the box.

And if you take away all of the JavaScript and all of the CSS on your website it will instantly become accessible and responsive.

Because there's none of that gunk to stop that from being there.

Anyway, the first web browser was called the World Wide Web.

But it only worked on the next computer which was the computer that was built in educational establishments.

The next web browser was built by a young lady called Nicola Fellows, brought in by CERN to work on that and it was built by her to work on all of the operating systems that were around, making it global.

The talk that was from last week in Brighton, just go to Jeremy's website and you'll find it.

It's like a 45 minute talk about how they went to CERN and rebuilt this browser from scratch and it's really interesting.

But before that we had loads and loads of... home computing became a thing in the 90s and people had these things.

We had this program called Encarta because the web did not have videos and images and audio and things like that.

My computer is making a horrible noise.

Microsoft Encarta was an encyclopedia.

It was kind of like a replacement for the encyclopedia Britannica which was a load of rubbish because it was one CD-ROM that didn't really have a lot of data on it and it was very, very, very American.

But it was kind of cool that you could click on things and things would happen.

So later on in the mid 90s we got two more languages.

One was called CSS and one was JavaScript.

The CSS made your websites look different and a bit prettier.

The JavaScript made it interactive.

So when you clicked on something you could say now I want you to do this rather than visit this other website because that's all that happened beforehand.

So we've got these new things that are now starting to take over from the home computing thing.

Even though websites could look cool, they weren't really embraced properly.

They were chucked in using a piece of software called Flash.

And we've managed to replace Flash.

The web continues to win.

And this is what a Flash website looked like.

Basically the Flash website looked like what's that thing that Jake came out with a couple of years ago where you can animate without view transitions.

That's what Flash was.

It was view transitions.

And the web has again taken over that.

It wasn't until 2000 that CSS was fully supported.

And I'll buy a beer for anybody who can tell me which browser fully supported CSS first.

I.E. 5 on the Mac.

David, I.E. 5 on the Mac.

So me at Microsoft built a browser that worked on a Mac and supported CSS before they did it on their own machine.

What the hell is going on there?

Anyway, so I'll buy you a beer later.

So then we got HTML5.

This was around about 2004.

And what the W3 said, they said, well, let's look at all of the divs that are out there in the world and find out what the IDs are on those divs.

And then they created these elements off them.

That's basically what happened.

They thought, oh, loads of people are putting a video in here.

Loads of people are putting a section, a header, a footer.

That's what they did.

They said, let's turn those IDs into semantic markup.

And that then came with area roles and all things like that that are down the future.

But I'm not here to talk to you about all of those things.

So we got semantic HTML.

Then in 2007, this dude came on the stage and he said, here is a little computer in your pocket and you're going to be able to build web apps from native HTML.

Somebody else came along afterwards and said, no, we want to prioritize that.

But that's a whole different story.

And if you want to know about that, listen to any talk by Alex Russell or any talk by Stuart or Bruce, and they'll explain why this turned out to be a bad thing in the past.

Anyway, that then brought us the loads of problems because when I was working in the web in 2007 and all of our clients said we need a mobile site.

So what happened is we had mobi.my-site.com and my-site.com.

And we were building two websites for the same company.

And it was very profitable for people building websites.

But it was a nightmare.

And then in 2010, a guy called Ethan Marcotte, and you mentioned him in the pub earlier, but I think it came along with this idea that websites could change shape whilst you were depending on what device you were using.

And that just meant we could use a fluid typography.

We were able to talk about that at State of the Browser last year by Richard.

Amazing talk.

And fluid layouts.

And it was at this point, up until this point, every client would go, no, it has to look the same on every single thing.

It has to look the same on this machine and this machine and this machine and this device.

And as soon as this came out, we could say, no, it doesn't.

So that was a game changer.

And again, the web caught up and it overtook and it won again.

Then in 2015, we came up with this idea of PWAs.

And all of these things that we've talked about, so responsive web design is just a three letter algorithm.

An algorithm?

Acronym, yes.

Three letter acronym.

This one was come up with and we'll talk about that in a second.

So what are progressive web apps?

Very, very quickly.

So it is a term that was coined by Frances Berriman.

Frances Berriman has a lot to answer for.

She's the reason that I am here tonight because she came and gave a talk at London Web Standards with Jake in 2009 and it was called Professional Bun Fighting.

And it was that day that I decided that I had to become an organiser so that I would never miss an event again.

So she has a lot to answer for.

And I think she's coming in March.

So I'm very excited about that.

Very simply, a progressive web app is a website.

It's as simple as that.

A PWA is a website.

Albeit a very smart and sophisticated website.

But just a website.

So let's have a look at what this means.

So we've got three parts to this.

P stands for progressive.

That means, this is probably the most important part of the PWA acronym.

It comes from the idea of progressive enhancement.

It means that you can build a website and you can put things on that make it better for newer machines and newer devices.

As long as your website works, remember we looked at the first ever website, it still works.

We could have progressively enhanced that with some CSS.

Or in the olden days, font tags.

But we now have more interest.

The second part is web.

It works on the web.

Which means that it doesn't matter what device you've got, all you need is a web browser.

It will just work.

Thank you for nodding.

And then the third bit is the app bit.

Nobody knows what an app is anyway.

You can't describe to me what is an app.

Nobody knows.

So, Francis said it's marketing.

It's just like HTML5.

It's just marketing.

HTML5 is just HTML.

It isn't a new number or anything like that.

It's just for marketing.

It's something that we can talk about in our blog posts or to our clients and things like that.

It's just marketing nonsense.

We'll talk more about that at the moment.

So, developers did say when she came out with this idea, because it was a woman that came up with this idea, so of course she was wrong.

Not.

They said it should have been called progressive web sites.

But, the name is just a distraction.

It is just for your investors, your marketers and things like that.

So you've got something to talk to them about.

You've got a label for this thing.

In 2004, a young man called James Garrett came up with an acronym called AJAX.

It stands for Asynchronous JavaScript And XML.

Nobody would ever buy into that.

But AJAX, well it's like a cleaning product or something that Flash Gordon flew into to Ming's palace.

AJAX.

It sounds cool.

It's a marketing term.

That's all it is.

Nobody said, "Oh, I am an expert in AJAX."

No you're not.

Unless you clean your toilet a lot.

And then similarly, Ethan Marcotte came up with this idea of progressive responsive web design, which was just fluid grids, fluid images and media queries.

That's all it was.

But if you say I am going to build you a website with fluid grids and fluid, people are going to go, "I don't know what you're talking about."

But responsive web design, it's a cool catchy name.

That's all these things are.

They're just cool, catchy things.

Because progressive web apps are built on web technologies, there is no reason they shouldn't be responsive and made to work on every device, even though we don't know what that device is yet.

New devices will come in the future.

So, progressive web apps are responsive.

Progressive web apps are connectivity independent.

This means they can work offline.

And we talked about this in the pub earlier.

Sorry, we've been to the pub before the meetup.

There will be more pub later.

So that means that we don't have to have the internet or a connection to the internet for our website to carry on working.

A normal website does need that.

A progressive web app doesn't need that.

They are app-like.

We don't even know what apps mean.

They're appy.

It's something that some designer has come along and done.

But they don't need that quote.

They are fresh.

This is the best bit about them.

They stay up to date all the time.

I'll talk more.

So, if I've got a native app on my phone and I haven't got the internet, I can't update it.

If I don't want to update it because I don't want to use my data, I don't update it.

In 2019, the Conservative Party had an app for all of their attendees and it leaked everybody's data into everybody's data went into everybody's phone who had that app.

Now, if I was a bad person, maybe like a Tory, I wouldn't update that.

And then I would keep everybody's data.

But if it had been a progressive web app, it wouldn't have just updated as soon as there was network connection.

And all of that bad stuff would have disappeared.

But if you're not, if it's a native app and somebody chooses not to update that, then it's not going to be fresh.

And progressive web apps are safe.

By default, they have to work over HS2.

No, no, we'd never get them if it was HS2.

HTTPS, they have to work over secure connection.

A native app does not need to do that.

They could just leak and send your data to whoever you like.

So why should we use progressive web apps?

So the web, I don't care what anybody in any company says, is the biggest platform in the world.

This is bigger than every Apple device in the world.

It is bigger than every Android device or Windows device, because it is a browser and it connects to this thing.

If you build a native app, it will only work on that device that it was built for.

If you build a progressive web app, it will work on any device that has a browser and fridges happen nowadays.

As Tim pointed out to us at the Olympics, it's a long time ago now, 13 years ago, this is for everyone.

Not everybody has the latest device.

Not everybody has an iPhone.

Not everybody has an Android.

This means if you're building a native app, it will only work on that device.

If you want to build one for all of the devices, you have to build multiple.

I know there is React Native and you can make it shipped to different things, but you've got to test all of those things.

If you're building a web app, it will just work.

Data is absolutely critical.

We are very, very fortunate and we are rich people.

You might think, "Oh my God, I'm a student.

I've got a massive loan.

I am not very rich."

Compared to some people in the world, you are still rich and you can afford data.

Some people have multi-sim devices.

One because they need to be able to make phone calls and this data, this package costs this much and one for data.

Different countries, people have different amounts of data.

So downloading a progressive web app is probably going to be a lot smaller unless you built it with React and you're shipping loads and loads of JavaScript, but you could abstract all of that to one side.

Downloading these apps, they're generally way, way bigger than it was.

Memories are way more important than the app on your phone.

I take loads and loads of photos.

Everybody takes loads of photos and I'm not going to delete my photos over your native app.

What I'm going to do is I'm going to go run out of space, going to delete this app that I don't even use.

I dare say that everybody in this room has probably got more than 10 apps on their phone and some of them they haven't even looked at for the last two years.

Yeah?

Memories are more important than your app.

So this just shows us how much data some apps are using.

That one there, obviously Netflix is some, I thought that was a load of TV shows that I downloaded, but no that's just the size of the app and that is almost one gigabyte, which is lunacy.

You could go to the website and watch it on the website.

Every step that you have in your app will lose you 20% of the people.

So if somebody's got to download the thing, some people are going to go, nope.

If you go to a website, you've already got them there.

So you've saved 20% of the people's time.

Almost no one uses an app after the first time they've used it.

They'll download it, use it once and then they'll never go back to it again.

If you don't believe me, have a look at your phone and look at the things there and you'll go, well I haven't used that in a long time.

We can easily, because it's a website, put analytics on so we can find out who's using our app and all of those kinds of things.

When you do that with native apps, you've got 12 sets of analytics because you've got one for Windows, one for Linux, one for iPhone, one for old iPhones, one for new Android, et cetera, et cetera, et cetera, et cetera.

You've then got to bring all of those analytics together whereas a website, one set of data.

So, we're going to quickly look at the technologies behind.

Oh, I'm on time.

That's all right.

Last time I gave this talk, I was 30 minutes over and it was only supposed to be 20 minutes long.

So we're doing all right.

So I'm going to show you an example of a progressive web app that I built.

I built a progressive web app called The Hitchhiker's Guide to the Galaxy.

Who's heard of this?

If you haven't heard of this, that's your homework.

Go home and read The Hitchhiker's Guide to the Galaxy.

It'll change your world.

Anyway, so here we go.

We've got a website and it is just some HTML.

Some HTML that is some headings, some text, some links that link to other pages.

And that's all it is.

So, what I'm going to do is I'm going to add to this using technologies that we've talked about to make it into a progressive web app.

So from this point, all we've got is we've got some text, headings and links.

This will work on the line mode browser that Nicola Fellows built all the way back there in those days.

It will still work.

In fact, all of the websites will still work because HTML and CSS are amazing languages.

If the browser comes across something, doesn't understand it, it goes, "Don't understand that," moves on to the next thing.

Just ignores it.

If it does that with JavaScript, it goes, "I don't know what to do," and just closes and shuts down and has a panic.

So not putting loads of JavaScript in your site is a good thing because if it doesn't work, your website carries on working.

So next thing we're going to do is I'm going to put some images on there.

And I'm going to put images on there using SVG because SVG is just text.

It's been around quite a long time.

It won't work on the line mode browser, but it's a progressive enhancement.

You remember I said that earlier.

It's progressive.

So in there you'll see the video's probably stopped, but there were some images going.

The next thing I'm going to do is I'm going to put in some CSS animations.

You see the text scrolls across as you click and things like that.

CSS animation.

If the browser doesn't understand CSS animation, it just shows yellow text instead.

The person using your website, if it doesn't work for them, they don't know.

Only the people testing on multiple devices will know that this thing is not working.

If it was some JavaScript that wasn't working, it would just go, "No website for you today."

But that's how it works.

So I'm progressively in it.

I haven't even used any of the cool technologies we've talked about with Progressive Web Apps.

All I've done is I've put in some text, some images, and some CSS.

So let's put in some progressive web app stuff.

So the first three parts that are essential for it to be called a Progressive Web App are secure service workers and manifest files.

You don't have to put all of those things on there.

Earlier this year, I went to a meetup about Indie Web Camp.

I freaking loved it.

It was brilliant.

The whole principle behind that is you can make a post on your website and go to everywhere else in the world and people can comment there and it comes back to your website.

Or you could start here and just have a website.

And then you could add things to that to make it better and more exciting.

But start somewhere.

So that's what we've done.

We've built a website.

We've put some pictures and some color onto it.

Now I'm going to put some other things onto it.

I'm going to make it secure.

I'm not going to talk to you about that.

That's just a protocol, HTTPS.

But we're going to put on some service workers.

Service workers are pretty cool.

And I think they are the best thing that Jake ever developed.

So this is before we talk about service workers.

I'm going to talk about how a website gets built.

So person goes to their computer.

They type something and it goes off to a beacon.

That beacon may be their Wi-Fi router or it may be a cable or it may be a telephone mask or something like that.

That telephone mask gets that data and it sends it to a thing called a server.

You probably know all of this but it's important that we understand what's actually going on here.

The server then goes, "Oh, okay.

You want some information from me."

And it creates a response.

And it sends that response to the mast and the mast then sends it to you.

There's lots and lots of technology and bits in between that we don't need to know about because we don't build those bits.

We build websites.

So from there, we then got our request responded to us and we've got a picture or some text on the screen.

So what happens if we put a service worker in there?

Does everybody know what a service worker is?

I don't.

Nope.

Cool.

Some people do.

Right.

So let's have a look.

So here, service worker is, again, this time, I'm going to make a request and this time it goes to a bunch of cops, my service worker.

And the service worker is, it interrupts that request and it goes, "Oh, what do I do here?"

It only does that if we've been to this website before.

If it hasn't been to this website before, we have never made that request and we haven't got the service worker stored on our machine or our device.

So the service worker makes some decisions, which we'll have a look at in a minute, and then it will go back to the telephone mast and then it will talk to the server and the server will talk to the telephone mast and the server at the telephone mast will talk back to the computer.

If we make another response and we've told the service worker what to do if I've been here before, we can do a number of things.

We can return requests straight from the cache.

So you can say to the service worker, "Somebody's been to this website before, store my CSS, store my homepage, store my JavaScript file," or whatever.

We can tell the service worker to go to the network or to that server to go find some more things.

We can tell it to cache things for the future.

So I want this page called /dave, haven't got that, go to the server.

If I want this page called /jonathan, been there before, I've got that, I'm just going to give it back to you straight away.

So that means I don't have to go all the way to this side of the world, to the server, to get that because it's on my computer or my computer.

That's what a service worker can do for us.

We can say, "Interrupt this call to the network and I'm going to make some decisions based upon what you're trying to do here."

We'll have a look at more detail about that.

We can check to see if there is a connection.

So first thing you can do is go, "Hello, are you connected to the internet?"

No you're not.

Okay, so here's ten jokes that I wrote.

And that'll keep you entertained whilst you're on the tube or underground or in an airplane or whatever.

We can set up some promises if something is not ready.

So, I promise you that the room will be ready on time.

If it is not, we can hang around that side and have a little chat.

And things like that.

So, lots of things that we can get the service worker to do.

So all the service worker is, is it's a file that says, "Before you go to the network, have a look at these things and see if there's something we can do here."

And that could be just give them a picture of themselves going, or whatever.

So, service workers have scope.

It's very important that they live in a specific place.

If you put your service worker in a file called /JavaScript, and we're just using service worker, sw.js as service worker, you can call it whatever you like, it's not important.

Then your service worker will only work in your JavaScript file.

If you want it to work on the whole of your website, then you must put it at the top level.

If you only want it to work for My Progressive Web App, you can put it in a folder called My Progressive Web App where it's being served from.

You might do that the opposite way around and have myapp.example.com/service-worker.

But, it has to be in the place where you want to use it.

So if you put it in the JavaScript folder with all of your other JavaScript, it will only work for your JavaScript.

So if you want it to work on your website, put it at the top level.

We can call a service worker using a link tag or using a script tag.

So in there we've got, here is the service worker, just like a style sheet, and there is a reference to my style sheet.

Simple, simple.

We can also check for features.

We can say, if my navigator or my browser has service worker, load it.

And if it doesn't, that means my piece of JavaScript there is not going to knock over and fall over my website.

Does that make sense?

Yeah?

Because we've already discovered that JavaScript is fragile as hell and if it doesn't work, it just stops everything that's going on in your website.

So if you say, does my browser do service workers?

Yes, then here it is.

If not, don't do anything.

Simple.

So, what's inside my service worker?

The first thing that's in there is a thing called the version number.

And this is really, really important because if you decide that you want your service worker to do something different, the version number is key to making sure that he can do that new thing.

In there, I'm going to give it a name for where I'm going to store my cached files.

Then I'm going to say, here is an event list there.

And that event list says, when this thing gets installed, I want you to do these things.

So I'm going to install, wait until you open my cache and in that cache, you've put my CSS, my JavaScript and my image for my logo or whatever you want it to be.

And then all I've done is I'm closing all of those brackets.

So all I've done is I've said, my service worker is version 0.1, 0.01.

I've got, I'm going to cache some files and I'm going to put them in a store called static files.

And then I've got an event listener that says, when this service worker gets installed, do this.

And it just says, put all of those files into my cache.

This is another thing that I've got in my head.

So in there, I've said, if there is a fetch event, so go and fetch something from the network.

I can say, well, hang about, first of all, does the thing in my caches match the request?

And if so, give it to out of my cache.

And if not, then go to the network.

There's lots and lots and lots of things you could do.

I just spent days talking about this, but there is a website that tells us about it.

It's called serviceworke.rs service works, and it's got a lot of recipes.

So if I am on a network and I've got something in the cache, return that.

If I'm not on a network or if I get the network, then put it into the cache, update my cache, all loads of things.

So they're called recipes.

It's just not, how do you do this thing with a service worker?

I'm not going to teach you that because you can just go to that website and copy and paste those things into your service worker.

And it's so simple.

So this is an example of my site where I've got service worker on it.

And at some point I'm caching those pages.

And then I'm going to go in and I'm going to turn off the network and my website will continue working.

Is that video stopped?

Yes, there we go.

So turn off the network.

I can see.

Can you see that?

Yes.

And the website is still working.

And that's because I've told my website, the service worker just says, cache these pages.

Now I've given it a list of all the pages in the website.

And I can do that because those pages are just text and they're about two kilobytes at the most for all of them.

So I've now got this thing that works when I'm lost in space.

So down there you can see the total size of my website is less than half a megabyte.

And that is, I think there was 78 pages.

And that was the whole thing.

So next thing we have is manifest file, web app manifest file.

You can use this for many, many things, not just your progressive web apps.

If you have this on your website, you can change the color of the Chrome on your browser.

You can change how the browser looks on your phone and things like that.

It's really cool.

So to build that and put it on our page, we have a link tag that says this is a manifest.

It doesn't work on every browser.

That's because some browsers don't think you should have progressive web apps because they're evil.

But that doesn't matter.

It works on some.

That's called progressive enhancement.

So in my manifest, I tell it what language my app is.

I give it a name.

That name can be then used in other things.

So if I save to my home screen, that's the name that I want.

Or I could give it a short name if I wanted as well, because 20 characters is too much for my home page or my device.

We can give a description.

We can give it a theme color.

That means when it loads, it has a color.

We can give it a background color.

We can give it a starting URL.

And we can tell it how to display that app on my device.

And we'll talk about that.

And then we can give it some icons.

So you might have a big icon, small icon.

I don't know, maybe you've got a super retina device that's four times normal pixels and any of that nonsense.

There's loads and loads of settings that can go into a manifest.

But basically you can say, make my browser this color.

So when somebody loads your website, it comes up in a nice color that you like rather than the browser of choice.

So what does display do?

Display does have three settings.

First of all, display browser, and it puts the browser's Chrome there.

The second one is standalone.

And what it does is it removes the browser's Chrome.

So now my progressive web app is looking like a full screen app.

And I haven't stolen away the bits of information that apps take away from me.

And I hate them for doing that.

I want to know how much battery I've got on my phone when I play the game.

Why do they do that?

Why do they take that away from me?

But you can do that.

And that's called full screen.

And you can see here now there is no battery and network connection.

So that's what those display settings can do.

Some browsers don't support this, but that's okay because it's progressively enhanced.

So what we can also do is we can get a splash screen and you don't have to do anything special to this other than give it a name.

We gave it a name attribute and give it an icon.

And all I'm doing there is I'm loading an SVG and is by an icon.

Cool.

So what I did there is I built a website that was just HTML, put some images on with CSS SVG, put in some CSS to make it look cool, nice colors.

And then put in a service worker to say, if you haven't got the internet and you've already been here, don't worry about it.

And then I put in a manifest to make my loading screen and things like that look cool and tell it how to look.

So I've got three very quick examples.

And then I'm going to go buy David a drink because...

So first example is the Final Show of Times.

They built a web app before the term progressive web apps came about.

They came up with this idea in 2010 when service workers came out.

And what they do is when you go to the website, all it does is it says, okay, just in case you lose your connection, I'm going to cache the 10 latest stories.

And that's all it does.

So that means if you're going to work on the tube, I know that the tube gives you the internet now, it didn't used to.

It's been progressively enhanced.

But it meant if you went underground and you clicked on something, you can go, no network.

It showed you that story because it pre-cached it and stored it on your browser.

Yeah.

Service working did that.

The next one was Pinterest.

They built a progressive web app and the case study is phenomenal.

And in different parts of the world, that progressive web app outperformed the native app absolutely off the scale.

So let's have a look at this and remember this.

The effect of launching the progressive web app, weekly active users on mobile web increased 103% year over year over year.

That was 156% in Brazil, 312% in India, 296% increase in session length.

So three times longer people spent on their progressive web app than the normal native app. 401% increases in pins seen.

I don't know what a pin is.

I'm not cool enough to know what Pinterest is.

I'm just not Pinterested.

Sorry.

And three, almost 300% of users were more likely to save a pin, whatever that was.

And increase in logins was almost 400%.

So, and the other thing is if I build a native app and I spend, I don't know, you've built native apps before maybe.

Yeah.

And you have to then submit that to Apple and they could have said, no, your nine months of work, we're not going to let it on our platform go away.

Nine months worth of work gone.

A web app is a website.

They can't take it down.

Simple.

When I was a teacher, we used to go around and watch the kids and what websites were playing and we would block everything.

One of those, but that was only on the school network because they were playing flash those and we were evil teachers.

And the signups increased by nearly 900%.

So as you can see, the impact of Pinterest building a PWA was just off the scale.

The third one was Uber.

In India, they built a PWA because most people, their connection was 2G and it worked on 2G and the whole app gzipped was 50 kilobytes.

Wow. 50 kilobytes.

So that's another reason for building progressive web apps rather than a native app that probably won't work on somebody's phone because the capacity or the data or whatever.

We've looked at why the web continues to win.

We've seen it all the time.

Recently, CSS has gone absolutely gangbusters and all of the things we used to do with JavaScript, we don't anymore.

We use CSS to do it.

I still want anchor positioning and it won't come this year.

I really want it to, but it will come and those things will go and we won't use those JavaScript libraries anymore.

We talked about what they are, we've talked about why you should use them, we've looked at the technology behind them.

It's basically just a website.

It's not ours.

And put some service workers and manifest them, make sure it's secure.

And we've looked at some examples.

At this point, thank you to these people who I got resources from.

Doug has been the most important one because he wrote the Hitchhiker's Guide to the Galaxy.

And if you've looked at the TV show, that's where I got all my graphics from.

But they hand through them and I use animations to do that.