I wanted to talk today about The Future of The Web platform because John asked me to which is a good reason to come to a conference and give a talk because the organizer asked you to.
And I honestly expected to not want to give this talk.
Six months ago, it wasn’t clear to me that the trajectory was up. We’ll talk about that in a bit.
But I think the question on a lot of people’s minds frequently is “Does the web have a future?” And I am not particularly good at prognosticating. I have my figures in a lot of pies though.
So as John mentioned, I am on TC39. I was thinking back on it this morning.
I think I went to my first TC39 meeting back in the dark days of ES4 which was probably 2006 or 2007 which means I’ve been doing this much longer than I’d care to admit out loud. Oh shit, I just did.
And I am on the tag with some of the folks who will also be presenting here, Mark Nottingham and Dan Dannacola who unfortunately, thanks to a technical foul, is no longer allowed to participate.
The foul’s not his. It’s the W3C’s.
And the reason this might be interesting isn’t about the technology itself.
These are all sort of how’s and what’s but they’re not why’s.
I’m a very bad predictor of the future; I don’t have a crystal ball. And if I did, it would be very, very hazy.
And that’s because I sort of focus on what we’ve just shipped.
So I think it’s important to understand that the truism about the future being here but not being widely distributed is incredibly true in software.
Our thinking about what can be is incredibly influenced by what currently is.
And it’s difficult for us to break out of the mode about trying to understand the world around us in a context of some future that we might be able to create.
I mean that’s the hardest thing for an individual to get perspective on a question.
And so my perspective isn’t particularly insightful but I’ve led teams that have helped design the future of web components, I led the team with [inaudible 2:16] Google.
We had our fingers in features like Promises and A Weights, and Async, and Classes, and ES6 All with an eye to a talk, we make it easier and better to build up applications.
Custom elements and web components are all about trying to answer that question.
How do you use subclass html element? How do you collaborate with the parser that’s in the browser to help you be more semantic about your markup and do that? I’m hugely excited to see that there’s talk here about web components and all these other things too.
So these are features that are not widely distributed yet like Google has polymer.
We’re building massive apps on top of polymer today. We’re deploying it at scale.
And our developers and designers are collaborating on top of custom elements and web components because it’s just markup, they can just hand it around and do it so that one worked, right.
We sort of looked at the platform and said, “Well, why can’t I play at the same level as the stuff that’s already there? Why can’t my code have a quality?” I came from the early framework wars. And in those framework wars, we spent a lot of time building frameworks so that we could build components, so that we could put components on a page.
The goal was never to build a framework.
It was always to build the components and to build the application.
So that’s an area where being able to participate in the platform that’s underneath you gives huge potential benefits to you as the developer and as someone who’s trying to compose an application, not necessarily build it off from scratch yourself.
And so we’ve sort of taken that mode and looked at how to think about all the other parts of the platform.
So in TC39, we’re doing what we’re calling archeology.
We’re trying to excavate the parts of this very rich platform that are already there and join the bits up that probably would logically be joined up.
We co-wrote a thing called the Extensible Web Manifesto but all of this is about giving you more power, giving you more power to build applications that are really rich that run very fast, that are easy to build, that are ergonomic to work with, that feel good, that aren’t hard because the web has a very steep learning curve today.
So that’s sort of what’s inside of the tab, what’s inside of the renderer process that’s all about making you more successful inside of the renderer process, letting you have a quality of the platform in these specific areas.
But we don’t have that in a lot of other areas.
So I think we should look back though and admit that we did really well, right? JavaScript being able to self host a bunch of these frameworks and libraries, being able to be more productive over time mostly by our own willpower, applying a lot more elbow grease to the question that html necessarily gave us credit for, learning how to do responsive design.
You know we’ve come up with a ton of really interesting and clever techniques and technologies for building great applications on the desktop and we basically won.
Okay, who uses Outlook? I don’t mean the web version.
Alright, I see a handful of hands. Who uses a web based email client? That’s what I thought. Okay.
But you don’t do that in your pocket, probably not anyway.
If you’re reading email on your phone, you probably don’t do that.
So I think we should try to set the stage and understand where exactly we are because we want a desktop just in time for mobile to eat the world.
It’s worth reflecting on Ben Horitz’s numbers from the mobile is eating everything talk which suggests that there are more mobile users in China than there are Europeans.
When I give my first talk about mobile Ajax in 2006, I dug up these slides the other day.
Luckily, they were PDF so they were hard to find.
And I had gone back and tried to do the archeology about sort of what it is that we were expecting the world to look like in 2006.
And the world that we’re expecting in 2006 was one that might have browsers soon.
2G networks were the norm, 3G networks were just getting rolled out.
There was going to be some incredible evolution in latency potentially with 4G.
Browsers were things like Obigo and Netfront, and if you wanted to develop for them, you had to get an emulator and run it inside of Windows because there was no such thing as an emulator chain for any other OS basically.
And the distance that mobile has gone in that short time is truly astonishing.
And I think it is important for us to be honest about where we actually stand with regards to that revolution because it actually is revolution.
We’re all carrying computers and I don’t mean on your back.
I mean in your pocket or in your purse.
This is some of the best data that we’ve seen so far. It’s got a lot of asterisks associated with it.
People spend about 85% of their time on their mobile devices in native applications.
We don’t know yet to what extent that encompasses things like apps that were built with hybrid app technologies like Cordova and Phonegap or Crosswalk.
We don’t what percentage of that is built in web views that people are using to have this sort of in app browsers that you see pervasively in social context today.
A lot of it could be web but it would be dark web but there’s good reasons to think that that’s not the case.
We think that a very large percentage at this time is being spent in native applications, actually in native applications. And 14% of the time is being spent on the web on the phone.
You know what they say that it’s always darkest before it goes pitch black? And that could very well be true for us too that it could be case, that we are a dying breed.
That would be really sad, but I have hope because it used to be the case that Java was dead.
I mean at least Java on the desktop, the client version of Java was a dead-end and nobody wrote in it.
If you have this same sort of twitch whenever you look at a swing application the same way that I do, you might understand why it died. But that sort of criticism is level that the web too.
It doesn’t quite fit in with my OS, it doesn’t actually feel exactly in the same way.
And if you thought that there was a growth trajectory for you as an objective C programmer in 2006, you had to be smoking something amazing. You would have been one of the few people I had the pleasure of going to MacWorld, an after party for MacWorld in 2006, and let me tell you.
The amount of grey beards dominating the room was impressive.
Objective C was not something that bespectacled hipsters writing fixies, art seasonally produced out of [inaudible 9:01]. That was just not a thing that happened in 2006.
So tides can turn, right? Dead technologies come back.
And I think all of that emphasizes to me is it has very little at all to do with the technology.
It’s certainly not the parts in technology that the tech press would like us to fixate on.
You might have seen this article floating around of how garbage collected languages are somehow going to be completely unrealistic for performance in every context whatsoever.
And if you have an Android device like billions of people do, you’ll know that you can get by just fine with the garbage collected language running in your UI.
That does happen on a daily basis. We have proof.
JavaScript being the world’s most popular language across every platform certainly is proof that you can do fine in the UI and you’re not up against some hard limit.
So we hear a lot of these stories about “Well, you don’t have access to particular sensors and you’re always going to be “behind” with regards to device capabilities” for reasons why the web is not just dead but is being buried and we’re currently filling in the grave and putting a headstone on it.
Those are the sorts of things that our community tends to tell each other about the dominant narrative.
And I’m here today to tell you that it has nothing whatsoever to do with the technology.
We need to step back a little bit and get perspective on the question of “What’s actually holding the web back on mobile?” I think this is incredibly indicative of this.
I followed a link from a tweet about an announcement about the W3C creating a new mobile friendly W3C checker. And this is the blog post that I ended up on.
I could double tap to make it partially readable but you sort of got to wonder if this is what we’re doing to ourselves and to our users.
Is this exactly the sort of platform that’s going to really get us where we want to go because this stuff is pervasive, this is everywhere.
And it’s, in the defense of other people who are doing better, W3C site looks like dogs.
As soon as you decide to make the desktop browser window be smaller too but this just emphasizes the size of the problem.
The assumption here is that everything is about the desktop form factor, clicks not taps.
The touch targets are too small, the fonts are too small. This is not about adapting to the particular UI.
We’ve had a decade of responsive design. A decade? We’ve had about a decade of responsive design thinking now instead of our community and we know how to do this better.
We know exactly what it takes to do a better job of this.
And it starts of having a viewport metatag which this sucker doesn’t.
So it is 2015 and we at Google have recently on the webmaster blog which it gets traffic there you can’t believe from everyone who’s trying to figure out what is Google thinking, have had to put this graphic on our blog in 2015. We just did this a couple of months ago.
This was the middle of a long series of posts about convincing people to go make decent mobile websites.
I’m not talking about killer websites.
I’m not talking about things that are optimized to the hilt of the network level.
I’m not talking about quick and speedy, although you should hear about those from Mark later.
I’m not talking to you about presending resources or the latest in Jzip and resource reordering.
I’m talking about basic, basic, basic here’s what it would look like if it all loaded.
The sad part is that in a lot of geographies, a lot of this stuff doesn’t load.
The abort rates for mainframe content are stratospheric in the geographies where phones are the only computers that people have access to.
It is astonishing that anybody retries to use the web at all.
And part of this is that no other mobile platform decided to try to run all of its desktop software when it made the jump to the phone.
We’re alone in deciding that you should be able to run desktop applications on a phone.
There’s a lot of reasons why OS vendors did this. They make a lot of sense.
There’s a huge body of valuable content on the web and because the web is so adaptable, well, yeah, you can sort of shoehorn it in there but you can do the same thing for windows.
There’s no reason why you couldn’t in theory run a Win32 application on a Windows phone.
There’s no reason why in theory you couldn’t make OS10 apps run on iOS in theory.
I mean universal applications, does anyone remember the transition between PowerPC to Intel? We had universal applications, that was amazing.
And now universal applications don’t work on phones or tablets.
How universal was that because it wasn’t about the technology, it was about the form factor.
It was about breaking those connections with the old world.
And there are no Swing programmers writing Android applications today.
And if there are, they’re certainly not writing them in Swing or AWT, or SWT, or the entire menagerie of UI toolkits that arrived inside of the Java world on a desktop in the previous decades.
This isn’t about necessarily the technology; it’s about breaking our expectations open.
So we as a culture are now receiving the comeuppance of having mistreated users and giving them the expectations of the desktop in devices that don’t necessarily work that way and don’t have the same connection guarantees.
And it hurts. As a user, it hurts. It’s undifferentiable.
It’s very difficult to understand which of these things are going to be appropriate for you on a mobile device, which ones aren’t.
Google specifically is at pains right now to try to talk to web developers to try to convince them with carrots and sticks that it is important both for users and for their brands to try to make decent mobile web applications.
And there’s a fundamental flaw beyond all of that, beyond what we decide to do about how to build our applications.
There’s an expectation about the web which sort of came to be when you sat down at home and you plugged in the modem and you started to dial up and you yelled to everybody else in the house that they better not pick up the phone because they were going to ruin your day and that download, that 5meg download for that mp3 was going to be ruined.
You knew that you were driving the web.
You basically put yourself in a cockpit surrounded by a very large screen and a keyboard and a special chair probably, the sort of chair that you wouldn’t let anywhere else in the house.
And you knew that you were driving the web. You were connected.
It was an explicit action. It was something that you did.
And what we’ve done on the mobile web is to take that model of assumption about how you navigate every link you click on is just a click away because you know that you were in this mode where everything is just a click away, maybe it’s a little bit slow but you’ll get there in the end because you know that you’re connected.
And we turned it into a surprise.
The way I think about this is if you took a mobile application, every mobile phone that you got today has some sort of basic set of native applications on them.
So think about those applications and then think about all the buttons in those UIs.
And then imagine that they’re sort of failing on you randomly whenever you tapped on them.
That they just went white, they just showed you a white screen.
And sometimes, they give you a cute little dinosaur and a game to play instead of connecting your call, Or instead of showing you the messages, or instead of letting you respond to that email.
That’s the web’s fundamental model which is that everything is just a click away.
And so we make it a surprise on the web today that something will work out, that when you tap on a link on a mobile phone, it’s going to be great.
This leads to great user frustration but more than that, it leads to fear.
These aren’t applications that you can trust.
They’re not keeping the basic tenets of what it means to be an application to be a first class citizen in this world, they’re just not really good enough. You can’t count on them. They aren’t dependable.
This is very much like kind of a cheeky relation you might have had when you were younger where you had someone that you really had a good time with and you would go out with them, and you always thought that was the greatest thing but you could just never convince them to sort of settle down, you could just never think about what it would mean to have a future with them because they were always off doing something. And they were never dependable.
You needed to move, you had to call a different friend.
You can never borrow their truck even though they have one.
It was just that kind of thing. That’s the web today from a user’s perspective.
We’re not a dependable platform. This really hurts.
And we do this to ourselves too.
We should note that even though it will be potentially possible for us to cash a lot of this stuff, because we always want fresh content when we go places, we send this.
We tell you, “No, no, no. Whatever I had, forget about it. I want you to go get the fresh stuff.” And this is how we can do up-to-date content because our model today smushes everything in to a single payload.
All server rendered content today on the web is basically a giant string smusher.
We take a bunch of data and a bunch of templates and we smush them together.
And then turn it into a single string and then we send it down the wire.
And we make that string get unsmushed on the client and then we make it do a bunch of stuff.
But what has happened there is that we’ve taken the navigation and all of the UI around the outside and all of the context for the application’s content, and we’ve smushed it into the content itself.
Like what does the URL actually address? Is it the stuff inside the blog or is it that stuff around the outside? This is an important question that the web has sort of never come to terms with but it’s now fatal.
It actually is killing us that you can’t reason about going to an application and not having to have all of that stuff around the outside come back at you. It would be much nicer.
And your native applications do this when they depend on a network if they were the ones to tell you.
If they were a relatively decent butler about their connections, if they said to you, “Well, it’s fascinating that you wanted to do that but I’m sorry my good man.
We can’t do that today. It’ll be just a little while. You might have to reconnect.” Instead, what we do is we give you a dinosaur. This dinosaur is very cute.
We’ve had to make it very cute because you see it a lot. It’s a bad experience.
And I think there’s a larger problem which is the web has no application model.
Today, if you build a web application in the normal way, it is impossible to tell what is a page, what is a URL, and what is an application.
There are some URLs that might be applications. They might contain entire universes under themselves.
And those of us who care about links and those of us who care about navigation, and care about deep linking and the future of what it means to have a searchable ecosystem of content think that that’s a terrible idea, right? Never having more than one URL for this entire universe of stuff, I mean pack it up, you should go home.
URLs are amazing. URLs are amazing because they give us the capability to relate things to each other.
And it’s given us all of this benefit and be able to create the world’s largest body of content which we can now understand and take use of everyday.
That’s incredible and we’re about to throw it all away if we move to a model where we have to think about one URL being the entire application. So that’s not great.
On the flipside, if we think about building apps the naïve way where every URL is exactly that, there’s no sort of continuity about the experience, no Ajax, no progressively enhanced UI that allows us to not reload that application shell every single time we want to do an interaction.
That makes it more trustable.
If we go to that model, well, now we’ve got this problem that nothing’s ever going to work offline.
Nothing’s ever going to be responsive enough to sort of meet users’ expectations about what a modern application is like.
And think about going to example.com/thinger.
You want to save it as an application. You want to think about it like an application.
Which is it? Is it example.com/thinger that’s the application or is it example.com? And how would you know technically speaking? How would you know? There’s nothing about example.com as a domain.
It’s just a domain or a DNS entry that tells us that that thing is an application.
What are the application’s resources? Where would we find them? What do they look like? What are the things that make the application the application versus the content that was smushed up and sent down the wire in this gigantic string? It’s an important question that our platform currently doesn’t have an answer to.
And it prevents us from participating as a first class citizen and a bunch of other interesting interactions.
There’s also a bunch of other boring browser stuff that has been in the way of making real progress.
And I won’t bore you with it but catch me for a point afterwards and I’m happy to send you the tiers talking about how we’ve had this straddled desktop operating systems like Windows XP. Chrome still runs in Windows XP.
You may have not run Windows XP in a very long time but I guarantee you that there are millions of people in the world who do every day and it causes us to have to pull our hair out on a regular basis because most of these boxes don’t have GPUs or they certainly don’t have drivers that we can count on.
So everybody else went to phones and they threw all their legacy stuff and they get to rethink what it meant to have an application platform. I’m like, “Oh yeah, there’s a GPU. Sure.” And we’re like, “Oh, there might be GPU.” And we have to run the same code in both environments.
And we started on desktop Intel 32-bit. We moved to 64-bit.
We moved to Arm, we moved to Arm 32-bit, we moved to Arm 64-bit.
Trying to make a browser fast when it’s straddled all that stuff is a Herculean task.
And it takes hundreds of engineers.
Every browser project is probably some total at least a hundred engineers as a result of the amount of infrastructure that we have to build and bring with this. It’s massive.
And that’s leaving entirely to the side the question of the input switch.
We tap, we tap, and we swipe and we do a bunch of stuff, in China, they QR code.
We do a lot of stuff for input now that we didn’t do on desktop, on desktop and in URL, and in searchings, and how we navigated on the web before typing and clicking was natural.
Our frameworks, our applications has been a long slow turn to move to a place where we sort of understand how to do all of those modes all at once.
And that’s slowed us all down.
So that’s the really pessimistic view.
And I didn’t come all the way to Australia to give you a pessimistic view.
So I hope you don’t leave right now in this talk.
It’s worth noting that a very, very, very large percentage of time being spent in this 85% is being spent in social and games.
Almost entirely all the money being made in native applications is being made in games.
And that isn’t a great business.
20% is other, and that 14% accounts for a fantastic amount of ecommerce.
People buy things on the web. They don’t buy things in applications.
The amount of money that it takes to acquire a user, to try to get them to download your application, install it, sign up back in from whatever account they thought they had, maybe they go through the lost thing and get their email password sent to them.
It’s just an incredible ball ache.
And most users don’t do it which means that converting the user from the notion that they should go user application to go do something to getting them through that flow to that point where they’ve decided to go and actually take an action inside of an application has enormous friction in front of it so very few users do.
Primarily speaking, commerce on phones happens in browsers.
The amount of money being spent went up last Christmas in mobile phones, not down.
And it isn’t all roses even on the frontend of the native experience.
Getting a user to install your application, just install, forget everything else, forget trying to get them to do anything inside of an application, getting user to install an application in the native environment costs $1-2 in advanced geographies.
Sorry, advanced is the wrong word.
In affluent geographies, it’s $1-2 per install. It’s $9 to get a user signed in.
That’s what it costs to do the advertising to get users to show up inside of your application.
And it gets worse from there. It goes up super linearly.
It is not cheap to get someone to buy something inside of an application which means that the set of applications that are reasonable to build to go try to do commerce inside of is very small.
Just the economics of it don’t work for most people who would like to play in this world.
And then there’s the zombie problem.
A very, very, very large fraction of apps inside of the app stores are unfindable.
They basically don’t have owners and you can’t get to them.
Many of them are unmaintained, and a huge fraction of them never had more than a couple of dozen users in the first place.
App stores are hit makers. They’ve got top ten lists and if you’re in the top ten, then life is pretty good.
And if you’re not in the top ten, life is atrocious.
The developer economics survey last spring indicated that 50% of the developers who bank native application, who would like to be making money using native applications can’t even afford to purchase their own tools based on the amount of money that they make on native apps.
They call that developer poverty and I think it’s great.
There’s a huge percentage of zombies, and a bunch of the zombies are made by people who are below the poverty level.
And the web doesn’t have quite such dire economic dynamics which is really interesting.
We’re much more stable, much more reasonable long term economic play even with all the friction that I talked about before, right? Remember that all of that’s happening against the backdrop of us sucking in so many ways.
Despite all of that, we’re still going to be doing something right, right? Like the men and women who make the web are not all morons.
We are doing it because there’s actual economic reasonable end user value sitting in there.
And it’s not the technology. So what is it? I think about the native application ecosystem like buying a lottery ticket.
There’s a lot of people who have a lot of money who are pouring that money into building applications because they think hoping against hope that this is going to be how they afford groceries this week.
It’s a terrible idea. It’s sad, right? It’s actually sad. It’s not a growth industry per se.
It’s not the sort of thing that’s going to be sustainable over the long haul.
And this other people who have won the lottery are fantastically rich.
The few set of applitions that users use every month are things that actually do drive engagement back to those applications.
The ability to be on the home screen, to be in the notification tray are really powerful in terms of encouraging users to come back to your applications.
So the narrative isn’t entirely broken. People who do win the lottery do get rich. It does happen.
But the notion that brands that continue to build native applications when the odds are very high that you’re going to be made poor for doing it doesn’t seem like a sustainable outcome.
But the poll is real. This is advice that we actually have to give actual developers in the actual real world in 2015.
We have to tell them “Don’t put a full page interstatial over your mobile website.” In fact, we’re telling them this explicitly in almost every post that talks about mobile web from the Google webmaster blog.
This is very sensitive real estate.
Those words go through dozens of PMs before they ever get onto that blog.
I could guarantee you, maybe not dozens, at least maybe half a dozen.
And they’re wordsmith to death.
And we’re repeatedly giving people advice about how not to abuse their users on the mobile web because everybody thinks that they’re going to win the lottery. They just have to try harder.
They just have to buy enough tickets. And this is a terrible user experience.
So let’s step back and try to understand what’s actually happening here because “native is everything” is not really the full picture and “mobile web is going to make everything better” is not really the full picture, right? It’s more complicated than that luckily. That means that there’s something interesting to learn.
What we see is that users use between 12 and 20 applications per month total on their phones.
That has nothing about install rate. That’s just the number that they use every month.
There are theories about why that is. Maybe it’s the difficulty in spatial navigation, maybe it’s the fact that there aren’t that many great applications in the world, maybe it’s very difficult to find good applications.
There’s lots of theories about why that might be true but that is the case.
But those same users are visiting more than 100 distinct sites every month, more than 100 origins every month.
This is from the reporting that we see inside of Chrome for the users who opt in to telling us something about their distinct origins.
This is fascinating like the friction to go and get to run a web application because that’s what’s happening when you click on a link.
You’re there. You’re running the application. It’s right there in your face. You’re running it.
You didn’t have to do anything else.
When you go to a web link, you’re actually running the app.
They run 100 apps a month on the web and they only run less than five times that from the native site which leads me to a bold statement which is the distribution is the single hardest problem in all of software, tt always has been, it always will be.
It’s not AI, well it might be AI.
It’s certainly not graphics not now working. Those are all very difficult.
But those are about enabling a world to happen. They’re not about making it real for users.
And distribution is the thing that makes it real.
We’ve learned this the hard way with the Chrome project where we’ve had to go in the desktop world try to get users on Windows who have IE or Firefox as the default browser to choose to use Chrome.
It’s a very hard problem that requires a lot of creative thinking to solve.
It requires an ecosystem that is amenable to it but it also requires that you be very creative about making sure that you reduced the number of things that users have to do in order to get your software running.
And it used to be much worse for native applications.
Native applications have always sort of had this friction.
Think back when you went to the store and bought CDs or DVDs of software.
If you’re old like me, you might have done this.
And it was great because you got home and you got to try it.
We don’t do that anymore but there’s still significantly larger amount of friction in the native app ecosystems that there is in the web.
You can’t just click a link and be running an Android or iOS application.
That’s not what happens. You have to go make a series of other explicit choices.
And it’s the friction that kills.
It’s this friction that causes users to choose to use more things in the web than other stuff.
Friction is the core of why distribution is the single hardest problem in all of software.
And this has a lot of impacts and it has a lot of inputs.
Those inputs are largely around fear and understanding.
It’s very difficult to understand what an application’s going to do to my system especially if it’s given superpowers of of the gates.
The web solved this by not giving you superpowers out of the gates; you have to go ask for them.
It’s a much better model. It’s better for users.
It’s easier to understand and it’s easier to have control over.
It’s a more trustworthy system in the long term.
Native applications have only sort of belatedly come to this model.
And even still, their default set of capabilities is quite high.
The friction of going through application store of trying to understand whether or not something is going to be good or bad, reading reviews, all that stuff, it’s very difficult like it’s difficult to navigate and it means that many users drop off through the process.
What we see is that application developers report that they lose 20% of their users in their conversion funnel for every action that they have to take.
The web doesn’t have this friction in a way; you click on a link and you’re running the application.
Now maybe it’s not fast, maybe it’s slow to load, maybe the other side of it was a poorly optimized desktop website and that reduces the trust that you can have in the web as a platform but it isn’t this bad.
We’ve nailed this. The web is a platform and as an ecosystem, continues to succeed because we have absolutely on the back of the brilliant and beautiful link tag and because of html, we have completely nailed distribution friction.
We are the world leaders in reducing distribution friction to running applications.
But again, we don’t call on applications if we don’t know what they are.
We don’t have an application model.
So what if we did? What if we had the ability to think about something as being a coherent application, to have access to that home screen, to be first class in notification tray, to actually be reliable and trustworthy when you’re offline so that users didn’t have to think hard about whether or not clicking on a button inside the application was going to lead to a spectacular surprise of failure? So I said that I was just going to talk about stuff that we’ve already shipped.
You may not be using it yet but that’s true.
All the things I’m talking about today are things that have shipped in Chrome 42 and later versions and are on the standards track.
We’re working with browser vendors to make them real in their browsers too.
All of this stuff is open. All this stuff is portable.
All this stuff is going to be everywhere that you want to be eventually.
But the first thing is homes screen access.
In Chrome for a long time, you’ve been able to click on some dropdown menu on some random webpage and click this add to home screen button which then pulled up something like this and you could maybe rename it.
I don’t know why you’d want to do that if it’s an application, it’s got a name.
And then you’d maybe get a desktop shortcut.
In more recent versions of Chrome, we’ve made it possible to feed that information from a single file but how would you ever know that this thing is an app? Even if it had all the attributes of what an application would like to be, if it worked offline somehow, if it loaded seamlessly, if it told you when it was about to fail, if it was dependable and reliable.
How in the world would you know that this thing is an application, nothing in the UI tells you? We’ve thought about this problem for a while. And this is flipboard.com.
This is the actual flipboard.com that you can go and you use today on your mobile phone on Chrome for Android.
And if you go to it the first time, obviously, it just loads up in a tab.
This is a website. It’s a tab in a real browser on a real website. That’s pretty good.
But if you go to it a couple of times within a couple of weeks in Chrome, we detect that it’s application like, that it has done all the right things to tell us that it’s an application.
And we ask you, “Hey, do you want to keep this website as an application?” because we’ve given it an application model, and because it’s given us the signal that it is an application, we can present the option to a user at a moment where we have pretty high confidence that they have come back to it, that they like it, that it’s not spammy, that it’s not the first time they’ve used this thing, that it’s got some value to them.
We can ask them, “Hey, do you want to keep this thing?” And it gets added to the home screen and from there, you can launch a full screen.
So this is just a website. This is not packaged differently. This is not made out of an Adobe air package.
This is not a Cordova wrapper. This is not a Blackberry web storm project.
This is not a Microsoft Windows application for JavaScript.
This is not something that you had to deploy and build a different way.
It’s actually just a website and it is on top of activity in your OS, even on older versions of Android which don’t have the same integration between tabs and the task switcher.
It is a real honest to goodness first level activity. You can do this today.
And the way that we’ve made this possible is we’ve given an application model using something called the scope for a service worker which we’ll talk about in just a moment.
We’ve also all this gunk that you generally put in the top of these documents that you would like to maybe allow people someday somehow if you can convince them that something like an application, all this gunk that you put in the top of your document, we’ve put in an external manifest.
So this manifest can be at the top of your document and it can point at a single file.
And that single file doesn’t have resources in it.
It doesn’t tell us anything about the content of the application but it just tells us the metadata.
It’s just like “Well, this is the icon, this is its name.” When you load it, open it in portrait mode, make it full screen potentially And when you tap on it, start this particular URL.
It’s just the metadata that we need to understand that your thing is application like.
So that’s alright.
It doesn’t require a lot of work. It’s pretty straightforward to do but it does require you to have service workers in TLS and responsive design.
I’ve called this progressive apps which is to say that they start life in a tab and then they progress to being upgraded, to be full screen applications in your environment.
They come to you from the very fluid, easy to get to, not apps permeated web, and then they turn into real applications.
Progressive apps are, I think, because we just shipped it, a part of the future of the web that could be the web that you could help make, the web that could be trustable, trustworthy, work well in all these environments.
The second aspect is push notifications.
When we talked to brands, when we talk to publishers, they tell us over and over and over again that the three things that they got to have in order to try to think about making investments in the web and not also in native applications are placement in the home screen, push notifications, and offline.
And these are all key aspects about reengaging users.
They talk about a lot of other stuff too, a lot of those other sort of things and the technologies base around native applications but this is the core.
This is the stuff that comes up over and over and over again.
And you can do it today on the web inside of Chrome.
This is a quick animation that shows you how website, it doesn’t have to be full screen app by the way; it can actually just be in a tab, can prompt you today in Chrome to ask you if you would like to receive notifications.
These notifications work even when Chrome is closed both on desktop and on the mobile web.
You’re able to get the reengagement that you would with native application without making a native application. You just make a really good website.
You just make a website that has all the right stuff in it. It’s taken all the right vitamins.
And I think it’s important to note that this doesn’t require the install step.
The user doesn’t have to decide to go steady with you before you can ever get permission to do anything together.
We’re just going to ask you like all rest of the incremental permissions like geolocation and quota about whether or not you want to do this in context.
And the last thing that’s really important is that in order to have a trustable trustworthy experience, you have to have offline that actually works.
And that doesn’t necessarily mean that every single feature of your application has to work all the time but it does mean that you’re responsible for understanding and delivering to the user what’s going on.
You’re in charge of communicating to the user about the state of your application.
It isn’t an app if it doesn’t run when you tap it.
I’d like to create the extinction event for this guy.
And to do that, we are going to need some browser technology.
But the bad news is that we have screwed this up since 2006.
The gears project which was an initial attempt to make offline work in the browser started in 2006.
And then we basically copied the same design and put it in the browser, called it App Cache, turns out, it was terrible. And we made a bunch of mistakes.
But those mistakes were largely about hubris.
We thought we knew what an application was going to look like from the browser perspective.
We sort of handed you prescriptive model about what it would mean to cache your resources and your content and it wasn’t very flexible.
And I think it’s time for browser vendors to have less hubris, to trust developers more, to put developers in a lot more control over what actually happens when their applications run.
And so after 10 years of failure, we decided to do something completely different.
And that thing is called the service worker.
Normally when you go to a webpage, app.html at example.com for instance, you’ll make a get request and then it will go to the network and you’ll get something back potentially or you might not.
Service workers are progressive enhancement about this particular system.
What happens is on the second load or whenever the service worker finishes installing because it happens asynchronously and in the background, what can happen is that request for app.html will start the service worker script which you’ve provided which you run.
It’s entirely programmable. It’s under your control about what to do in this instance.
But the pattern that you should probably adopt is that having previously cached something about the outside shell of your application, send that back to the browser immediately.
So you’ve got some UI running that you can now communicate to the user with.
You can say, “Hey, this is what’s going on.” And then at the same moment, you can create a fetch out to the network to go get content potentially stale content from the local cache and then go get the new stuff.
So you can put up a spinner that say, “Hey, this is what I knew and here’s the new stuff that you can go get for me.” And then we can go to the network and maybe that fails, we can tell you that it failed, but your application is up and running.
And because this cache API, and the service worker API, and the fetch API all work together to give you the ability to create this experience when you’re offline or even when you’re online, you have the ability to think about loading a shell of an application and then fetching content.
It’s all programmatic, it’s all under your control, and you can do this today inside of Chrome and soon, Firefox.
The best case scenarios is when we get the new content and you can actually tell the user, “Hey! It all worked out.” This is pretty good.
This is how the best native applications and desktop work.
And because of service workers, you have the power to implement this exact same pattern inside of your application on the web today.
It’s important that you treat service workers like progressive enhancement, and we spend a lot of time trying to make sure that the system that we designed encourages you to do so.
Service workers aren’t blocking your first load of a page.
They download asynchronously and install in the background.
They take over later. They are not something that happens in the first page load.
So you’re going to continue to have to have story or an application that will work for users of older browsers or clients you don’t understand or have service workers.
This is pretty good. I think this is a compatible, reasonable fast forward for the web.
And one of the most important things about this is that it will create that trustable experience.
We have 1000 ms to get something on screen. We mostly screw this up. We generally don’t do this.
If you have a 2G radio in the way, you can never hit it ever, as if your radio is cold or it’s in a deep sleep mode. You can just never do it.
You can’t get the radio up, you can’t get a TCP connection started.
You can’t do DNS TCP and TLS handshaking and enough time to finally get bytes on screen in less than a second.
Maybe if you’ve got a warm 3G or 4G connection, you can do this.
But wouldn’t it be better if we were getting bytes on screen because you already had them? And then we did this traversal through the network potentially in response to understanding that the application was loaded and wanted some new data.
Hiding this away and giving users context, giving them back the shell of the application immediately is the most powerful thing about this.
And for users who are in geographies where latency is high, see Australia, or where connectivity is poor, most of the world, this is an incredibly important shift in the way that we architect our applications.
And those applications run on a bazillion devices.
Progressive responsive design is the key to making this next generation of web applications happen.
And so the application install for that you saw before requires that you have a service worker, it requires that you use TLS that it’d be secure, and it requires that you have responsive breakpoints.
So you have to do something offline. It’s up to you what it is.
But if you want to get that application installed for, you have to do that.
And you have to be secure so that you can be trustable.
That’s the only time that we’re, as a browser, going to allow you to enter into that contract of being one of those trustworthy things in the home screen.
So I know that I’m nearly out of time but I just want to show you a very quick, simple, progressive app.
This is the dumbest thing that can possibly work.
This is a thing that my colleague, Paul Kimlan built.
And let’s see. I [inaudible 45:02] that audio. Yeah, I do have audio.
This works on a phone too. You can just go here and it will do what it says in the ten.
It will blow an air horn every time you tap on the button. Okay.
Using web audio, we have evolved, truly.
Today in Chrome, if I go to this, if I reload it, what you’ll see is that first time, I didn’t have a service worker in this list of scripting context but now I do.
If I switch over here, I can go for the sources tab and let’s see.
Here’s my service worker script. And what you’ll see… Let me make this a little bit bigger. I apologize.
What you’ll see is that when it decides to install, it goes and it adds a couple of resources into the local cache which is under programmatic control from the service worker which means that whenever you fetch for the resource itself, even as the root, it’ll come up at the cache.
This is the simplest thing to do for building an effectively static responsive application.
This doesn’t encounter a lot of complexity but in this fetch handler, you can do whatever you want.
You can do client side routing, you can do client side templating, but effectively from the server perspective, you can do all the things that you wanted to do.
But if I load this in a browser that doesn’t have service workers, it’s still going to work because this is a web app. This is actually just a URL, right? This is what progressive applications are.
And if I visit this on my phone, it will absolutely work.
And if I come back to it a couple times because I go to a couple of concerts or something where I have reason to be annoying, I can be told that it will work as an application.
The other important thing here is if I view source, in addition to have responsive design, it has this manifesto Jason file. And this manifesto Jason file is just as simple as the one we saw before.
It’s just the resources that we need to know to tell you, “Hey, this thing is an application.” So if you have a link to a manifest file, if you have a service worker, if you’ve served over TLS, if you have responsive design, we’ll treat you like an application.
So this is the core of what progressive applications are. Cool.
There’s a lot to talk about in terms of frameworks and how you might architect your application to take advantage of this new world, how you might build your applications in a new way that’s both compatible and progressive.
It’s a huge topic. And today’s frameworks aren’t necessarily are all bought in on how to do this right.
Service side frameworks aren’t always there.
This conversation about isomorphic JavaScript in frameworks is something that is interesting and in this same area.
But today, the way to think about this is that to get set up for success here, you have to have TLS.
Your website must be server over SSL. This is the new norm.
By the way, you should never be talking to anybody, a CDN, or a hosting provider, or an application vendor who charges you more for TLS. It’s now part of the baseline expectations.
The days are over when you can be gouged for it. Do not play ball with that.
On the client, you need to be able to render some content.
That is to say you need to be able to have that first load no matter what else happens.
That application shell has to show up.
And you have to have a local data model and potentially think of synchronization because if you work well offline, that means that you’re going to allow people to take actions on their application data offline and you have to do the right thing when you come back online.
We’re adding new features in the browser in the near future, things like background synchronization which are going to allow you to think about how to schedule that work in a more reasonable way but you’re always going to have to continue to have a model that works with local data and synchronization.
Anyhow, thank you so much.
This is an incredible lineup of talks and I cannot tell you how excited I am to see the rest of it.
Thanks again!