Put your hands together for a man many describe as Paul Kinlan, it's Paul Kinlan.

Thank you, everyone.

It's absolutely great to be here.

I'm kind of honored to be here, because it's such a great event, and it's an amazing venue.

Yeah, I'm Paul Kinlan.

I'm going to talk about things, once they come up on the screen.

Hey, a black screen.

And the reason why I've got this, is because I flick backwards and forwards between my slides all the time just to test them.

But I never actually nearly made it to this conference.

And the reason was, because it's my son's birthday.

And I was speaking to the organizers, I was like, yeah, I'm going to have to do the first day, and leave really early, because it's the same day as my son's birthday.

And I don't want to miss his birthday.

And then it turns out, I actually don't know my son's birthday.

It's tomorrow.

But I was speaking to him just before I left.

And I was saying to him, what would you like for your birthday? And he didn't really answer.

But he did say, how would you say happy birthday in Dutch, and I have no idea.

So, after three, if anyone could, in Dutch if possible, or your own language if you need to, just say, happy birthday, Jack.

One, two, three.

(audience) [INAUDIBLE] OK.

We won't be able to work out what that said, but it's cool.

And the really cool thing is, I don't actually have to buy him a present now.

So you're saved me a lot of money.

So it's pretty cool.

So, yeah.

I've tried to treat this like a film, because we're obviously in a theater, or movie theater.

So I've tried to style this whole thing thematically around the idea of a movie.

There's always a main protagonist, doing some really cool action shots.

There's always a hint of a love story, we don't actually know whether it's going to exist or not.

And they normally tell you about everything you need to know about the film in the first five seconds.

And sometimes they even tell you the ending of the film.

So, given that we've already seen the trailer, Jake, should we do the questions? No? OK, cool.

Keep going.

OK, so there is a huge amount of change that's coming in the browser space, and that's what I'm here to talk about today.

And I'm here to talk about how I think we can all adapt to this change.

Because we're going to have to deal with change, we can't stay stuck in the past.

And it's one of the reasons why I do what I do.

I'm in the developer relations team.

And I like helping, and educating developers to build better web applications, specifically for mobile.

And I like to tell people how to do this in the real world.

And fundamentally, I believe that every single application and website, or piece of content, should be hosted on the web, deployed on the web, and accessible by a browser.

But when you look at the way developers are starting to build applications today, we're still using the technologies from two, three, four years ago.

Were not necessarily always focusing on mobile.

And I want to change that, and that's what my job is, and that's what, essentially, my talk is going to be about.

I pulled this out of Wikipedia, and a bunch of other resources, and everything.

And I apologize to my friends, Opera, I didn't have enough space.

And I'm a terrible graphic designer, so I couldn't actually do anything really cool.

But this is kind of the pace of change.

Basically, in about 2010 we started seeing browsers with the rapid update cycle.

We got to the point in about 2012, we were getting 6-- well, this is more-- 7 releases per year, once every six weeks in the case of Chrome.

And this is actually really cool, because every six weeks, in Firefox, and Chrome, and other browsers, we're starting to get more and more new features.

The feature parity, or the parity of the scope of the platform is increasing.

But the really cool thing here, is the amount of parity between browsers is also increasing.

Because every six weeks, Chrome tries to keep up with Firefox, Firefox tries to keep up with Chrome.

Internet Explorer comes out with a version that just brings more parity to the web.

Makes everyone's lives a lot easier.

And I think that's actually really cool.

But how do you actually deal with that change? And I think that's what my talk is about.

I say I think, because I want to see what comes out at the end of this and the questions I get.

But this is my story about the web platform.

This is based off of an article I wrote maybe about six months ago.

And it's a story about the web.

Where it's been, where we are today, where the focus of the browser vendors are.

And I can look at the future and where I think we're going to go in terms of-- well, maybe not in terms of features, but I think where the browser itself is going to live.

And, yeah, so this is my talk for today.

And, like I said, I've kept it like a movie theme.

So it's like a Quentin Tarantino film, it makes no sense.

It will be completely out of order, so the last bit is at the start.

I have kept down on the swearing, and the gore, and the violence, because I can't draw.

I can't do anything that's really cool.

So it's all black slides with a bit of white text.

So we'll start off with the last chapter, or essentially what will be the last chapter, what will be.

And this is the future as I see it, based on the analysis that I do over the scope of the web.

And where I look to the next set of trends I see for an end development going.

And it all started with a murder.

An assassination of App Cache.

It was actually killed by a young punk we think is called Jake Archibald.

He said basically there's a lot of angry arguments, swearing, someone called someone a douche bag, it got really messy.

But, basically, App Cache was dead on arrival.

We thought it would actually help us build great mobile web applications, and desktop sites that worked offline.

And it was kind of hailed, and like me, my team, and everyone else, also talked about App Cache as being the savior for web developers.

And I think we over promised, and completely under delivered on this API.

Now, the interesting thing here is that, everyone at the time thought the reason why apps on mobile platforms was successful was because they worked offline.

And App Cache was designed to make it work offline.

And whilst it did, it was hard to work with, it was a pain to use.

And, as Jake found out, when he was kind of at Lanyrd and everything, it's just full of holes.

And it doesn't give you the control that you need, that you want, inside your applications.

So offline is the first step to building great web applications that work offline.

And we saw that yesterday.

But we don't know the patterns and practices that we're supposed to use, because we're so entrenched in this online mentality of building applications.

So it's not great, it's kind of dead.

What's going to happen and replace that? Well, it took a while, and I think everyone's been talking about this today.

Basically, the theory is, there's a revolution happening.

With people like Jake, Alex Russell, and a whole bunch of other people who are trying to push forward either the idea of the extensible web manifesto, and I'm going to talk about that in a minute, or the idea that you should be able to have these extra primitives of the platform that let you do even more.

I'm going to talk about what this means to the web, and it's not necessarily about building offline applications.

Because the first time that you use a Service Worker, and you install inside your site, it's not going to work offline.

You have to add that functionality in.

But that's a really good thing.

And I want to talk about two or three things which are important, the ideas behind this change to web developers.

And we're going to have to deal with this, we're going to have to potentially change some of the way that we build our applications, or think about building our applications .

But the good thing with Service Worker, it's quite progressive in the way that you actually start to build applications.

You don't have to have offline always in your applications, because you can enhance your application with offline support.

Likewise with other pieces of technology.

So, the first thing that the team was really interested in with Service Worker, is that they believe that every single application or site, if it wants to, should have an application lifecycle.

Now this is my passing of the spec.

It's probably not exactly right.

But the reason why we've got this at the moment, is because every single website and web app is ephemeral.

What ephemeral means, is that when you go to the browser, you start to use an app, whether its Gmail, or whatever.

You use the app, you finish with it, and it's gone.

So it lives only in the time that the browser, or the user in particular mobile is actually on that page at the time.

And the really interesting thing about Service Worker, it's saying that you should have the ability to have a little bit more control over how your application life cycle lives.

So the browser, or the system, should be able to say, well, actually, this system is running.

It's running independent of a web page in the background, and I can do some work.

I can maybe intercept some web requests and a bunch of other stuff, that's pretty cool.

Or this phone, or the device, could say, well, actually, we haven't got enough resources.

Go to sleep.

Right? And it will actually put the Service Worker to sleep.

It won't take any extra resources up.

Now the interesting thing from here, once it's asleep, you might get some notifications from the system, which will end up re-invoking your application so that you can actually process some actual logic.

And this is not what we've had on the web before.

And this is what we're going to be able to deal with.

But we're going to be able to build applications that actually cater for this on browsers that support Service Worker.

And I think this is pretty nice.

Every time you look at a native platform, whether it's iOS or Android, one of the first things that you see is an application lifecycle.

And we're starting to get that on the web, and I think that's pretty powerful.

I don't know why I'm reading the slides, because I've got them here.

Every developer should have control over the app stack.

Now, there are various things that are coming in the realm of service worker.

The first is the ability to make your applications work offline.

Now, what this means here is, that you're able to intercept and manage every single request that comes through the Service Worker.

Your web page, or your web app, makes a request for an image.

You can decide what to do with it.

So you can basically say, I'm either going to get this from the cache and return it to the user, I'm going to make the request out to the network, maybe store the data for later, and then return that to the network.

But the idea behind it is that you get the ability to control all the requests that come through your application.

And you get to decide what you want to do with it.

And that's actually pretty powerful.

As a web developer, we've never had that before.

App Cache never gave it to us, for instance.

Also, we have the ability to handle push messaging, inter application communication.

We get the idea that the application has been installed.

Not necessary from the add to home screen way of installing it, but you get to decide what you want to do when the Service Worker is installed into the browser.

So you go off and preemptively cache all the data that you need for the user to be able to use their application.

And you should be able to build higher level APIs.

And this is essentially the fundamental thing about the extensible web manifesto.

Is you should be able to build high level APIs, platforms, off principles, like the fundamental principles.

We heard this yesterday from the web sockets talk where the question came up, why don't we have sockets in the browser? And there's a lot of reasons why we don't have sockets in the browser.

But the idea behind a socket, is that you should be able to open a TCP connection up, or a UDP connection, make a connection to a server, do some work.

And once you've done that, you can build higher level JavaScript APIs on top of that without having to wait for the web platform to catch up.

And some of the stuff this reminds me about is that, if we had Service Worker quite a while ago, we might have never needed App Cache in the way it was, right? Because we get to build our own App Cache.

There will be people building application frameworks and libraries that let us build App Cache, that let us do things like Web Intents, which is dead, unfortunately.

But be able to do inter application communication, all because our application can live in the background, be woken up, and do some interesting things from it as well.

So there's a lot of different things.

I put like scrolling in there, because one of the interesting ideas behind where some people are going, and it's not necessary inside Service Worker, is that we should have complete control over of the rendering in the layout.

I don't know actually know whether that's going to be a good thing for developers, but people seem to think it is.

So this is getting to a point where I'm trying to coin a phrase, and it'll probably never take off, but the idea about this is like the headless web.

Now, we all know about headless WebKit, and headless Firefox, that we use neither Casper or Phantom to automate unit tests, potentially take screen shots to see how responsive our website is.

Well, what I'm trying to get to here is that we have these tools and frameworks, we use them inside Google as well to analyze pages in the context of a browser.

So how does this page render with JavaScript enabled? Will that's how we actually do some search stuff.

That's pretty cool.

Well, that's the headless web, or that's the headless WebKit side of things.

The headless web is, once our application lives in the background, we have a background script of Service Worker that can do stuff, be woken up, and be activated whenever the system things we should be activated.

Maybe we get a cloud message that's been pushed to the servers.

Well, we don't necessarily need a browser service anymore.

We don't have to have a renderer for our application to work.

And that's actually kind of interesting, because we can start to build applications where it's all essentially JavaScript, HTML, and CSS.

But we never actually get the renderer, but we can still have users interacting with the application.

And I think that's actually pretty interesting, because obviously we get-- Jake is the only person who's got the phone set up with the notifications-- but basically my browser can take a notification from the web, essentially, a push notification, or push message, fire the notification off, and then ping it straight to the watch.

No web based user interface is actually ever needed in this whole transaction.

And I think that's actually pretty powerful, because when you look at the way Google watch is going, they want you to do interactions, short, lightweight interactions, on the device.

So say it's Twitter, for instance.

You might get a tweet that comes up, you favorite it, or retweet it, and then it goes and performs an action.

And right now, that's purely the native level.

Now if you get to the idea of the Service Worker living in the background never having a visible use of web based interface.

Well, you could have this point where you press retweet, or favorite, it goes back into the logic of your application, never shows any user interface, but actually does that retweet.

And that's actually pretty powerful, because we have a native level user interface powered by the web essentially in this case.

And you get one level further, and I was looking at this-- and I helped out with this for Google I/O-- is we have this idea of the physical web.

And physical web is a Scott Jensen project.

But the idea is, the idea about this is that, all around us we have Bluetooth low energy devices constantly emitting URLs.

And your phone is able to do this scan, look around for interesting URLs, or pages that are around it.

Get the URL, and then it will do a scan of the page, of the URL, and can return some interesting metadata about this.

And I built all the service infrastructures, I did this side of things here on the right.

But essentially, we get that URL, we go out, query it for interesting metadata, and then display that to the user.

Now, in this case, obviously the user might open up a web page.

But you can get to the point where you can define actions, and you can define entities inside the HTML, the area that we, as front-enders normally deal with.

You can find all the actions, and the objects that you want to interact with, and present them through a user interface that is not the browser, but it's powered by all of our kind of technology in our stack.

And I think that is pretty powerful.

Obviously we've got things like Google now, as well, and Siri and Cortana.

This data here, it doesn't look like we should have any control of this as front end web developers.

And naturally, with JavaScript and CSS, we don't.

But all of this data is actually pretty much rendered, or passed out from the underlying mock up of the page.

And I think that's actually pretty interesting, because we as web developers, we're going to have a lot more touch points across all the mobile and desktop systems that are not necessarily just the browser.

But then fundamentally are powered by web content.

And this is a relatively contentious one, because I actually believe that the web should be-- we should be able to get our content from the web, access it via URL.

Whether it's from search, or Twitter, and all these other places.

But there are services like deep app indexing where, basically, you have the content on the web, but it opens up in the native application.

And Tim Bray has been starting to talk about this.

He's trying to say that, actually, the web as we know it today, might never have a web browser that we deal with.

And actually, the new web browser is the application model, like the application framework behind it.

It gets all the data from the pages in the structured content, and then displays it in a way that is native.

I don't know what to think about this.

I still want the front end to live.

Like the browser side of things to live.

But there is a definite move of people going into this place at the moment.

So if you want your web to live, and not die behind all these native platforms, this is the man you want, Jake Archibald.

If you see him, capture him, because he's ruining the web as we know it.

I'm joking, obviously.

I like Service Worker.

It's going to be really good.

So I think, this is my last slide, my question would be, what do you want the web platform to be? Do you want the web platform to be for documents, which is primarily what it's been for in the past? Or do we want to try and build compelling applications on top of that? And if you want to build compelling applications, which I, personally, think we do, I think everything should live on the web and be accessible by a browser, what is the state of the platform? So we have to always look in the past to understand where we're going to go.

And when you look at the past, you can actually work out obviously the trajectory of where the platform is going.

And I made a fanciful guess, and a leap in the previous chapter.

But once you understand where we're going, you can actually start to tactically learn what we should be, as an industry, focusing on next.

So it always starts, again, with a proper love story.

And it wasn't actually a love story between me and Jake.

It was a love story between me and a service on the, yeah, service on the internet.

Caniuse.com, if

you've never used it, it's absolutely amazing.

As we saw yesterday, it's not 100% accurate in terms of understanding the features and capabilities of the platform, and giving you the right information.

But it does a pretty damn good job.

And it's kind of community source and crowd source, so you can write tests for it to make sure that we have historical information as well.

But with this, you can look at individual features, and you can see how well they're supported going backwards in time.

So you can see maybe IndexedDB landed.

Well it's available now, but it's been available in Chrome for the last two years, maybe in Firefox for the last two years as well, for instance.

It's pretty cool.

But it's not actually the site I love.

I really like the site, I think it's really powerful.

The really, the really, really good thing about caniuse.com

is the actual underlying data.

Because it's an open project, you can do pretty much whatever you want with the data.

And the guy who makes it basically, he gives you access to the data.

It's free of charge.

You can pretty much do whatever you want with it.

And once you understand that data, you can actually start to do some deep analysis, and structured learning, to understand what you should be focusing on next.

And also, more importantly, how you can actually start to move away from Internet Explorer 8 by tactically targeting different APIs based on browser support.

So I think it's really cool, and it's really powerful.

And I'm going to dive into all the stuff that I've done with this, and how you can actually do the same type of things with this as well.

So we all live in a world where we have to deal with minimum browsers.

Who has to deal with contracts with IE 8 as the minimum browser? Yeah, it's quite a lot of people.

I think everyone has to do that.

And what I want to try and do as an industry, is move away from that.

And this is what I'm trying to get at with this talk, is because I think there's a lot of times where the client mandates full support of Internet Explorer 8 for practical reasons.

They look at their analytics, and they'll say, ah, 3%, 4% of our traffic is from Internet Explorer 8.

Therefore, we must make it work completely and expect full parity with all the other versions.

And when we're building applications, they unrealistically expect this to happen.

And this is not a model that we actually want to be in.

We want to have users be able to look at something on IE 8, but maybe you don't have all the same functionality.

So this site, iwanttouse.com, is entirely

based off caniuse.com's data.

But the idea is that it gives you tactical guidance about what you should be looking at in terms of features, and how you can actually get the associated browser support.

So, for instance, you can look at-- say you want to build a web gel game.

Normally, if you're building a web gel game, you probably want Web Audio.

What is the reach of those two different APIs combined together? And what browsers can I target when I look at this? And then, once you understand that, you can actually make some pretty good decisions about when you're in contracts.

I'll talk about the contract work in a minute as well.

But yeah, we are stuck in a world of IE 8 at the moment, and we need to get away from it.

And I just want to highlight one point.

I was talking to-- and it's completely on the bonkers scale of things-- I was talking to a large company in the UK, and the reason why they didn't go mobile was because 10% of their traffic was from Internet Explorer, 10% of their revenue, sorry, was from Internet Explorer.

Which is actually a large chunk of revenue.

But the way that they had actually internally structured the contracts, and all the internal systems, was that they could never let Internet Explorer traffic drop below 10%, right? Internet Explorer 8 traffic drop below 10%, because they don't meet their internal targets of growth.

And I asked the questions like, well, why don't you just try and get everyone else-- massively increase the revenue on front end lead in browsers, like whether it's Chrome, Firefox, Opera, Internet Explorer 11.

You make some really great, beautiful experiences that work well on there.

And they're like, yeah, we get it.

It's just our management say we've got to keep the revenue on IE 8.

So even if you're actually increasing all the revenue on IE 10, 11, Firefox, and the latest browsers, you actually have to increase the revenue in Internet Explorer 8, otherwise, unfortunately, someone gets fired.

And I think that's the most extreme outcome.

But I don't think it's unique.

I think it actually is quite widespread.

So if we consider IE 6, IE 8-- and this is kind of like the original part of my talk-- was if we're looking at the ubiquity of the web, and you take it a completely non-pragmatic level, so you take it to the most extreme, we have about 15 features that we can play around with when we consider IE 8.

That's if you're not doing progressive enhancement and a whole bunch of other stuff.

And I think that's actually a pretty bad state.

We don't get a whole load of stuff for that, we don't get local-- do we get local storage? No, we don't get local storage, and a bunch of other things, which are actually pretty cool.

And my worry from everyone in this audience is that everyone gets forced into this model of always catering for Internet Explorer 8.

And having to treat that as the minimum baseline, but also having to treat that as the only-- like you can't have features outside of that.

And it's a problem in the industry.

And it's a problem with a number of developers I speak to.

And the only way that I can think about solving it is in a little bit at the moment.

But, however, if you do start thinking about features, you can actually start to think about, well, I'm going to talk to a client, and I'm going to say, if you-- not drop 4% of your users, but if 4% of your users don't get this advanced functionality, what features do I get to play with? So, for instance, if you're dropping 4%, obviously you get things like cross origin resource sharing.

But essentially here, the scope of what you can play with, the type of sites and applications that you can build, is actually pretty compelling now.

You can actually do a lot of stuff.

So we do, I think everyone knows this.

We are in a world where mobile, if it's not king already, it will be.

Mobile traffic is roughly about 23% of global internet traffic.

When you go to places like India, and the Far East, it's getting to about 60-70%.

And I can see that 60-70% actually rolling out across the globe.

But the interesting thing for me is that even in India, developers still don't get mobile quite right.

And that's one of the things that we need to try and fix.

And I don't actually know how to do it just yet.

But, the thing is, when I also talk to a lot of the developers, is that mobile opens up a huge amount of new baselines, right? So I've talked to a lot of developers, and one of the things that they said was, well, we have to deal with iOS 6 now.

iOS 6 on your baseline.

That's actually pretty cool.

iOS6 is a really capable browser, you can do a huge amount of stuff with that.

So does that all the features that you can support there, does that translate across the desktop? And they're like, no.

It's for IE 8 still.

And when you compare that, when you have those two baselines, we can't actually build compelling sites.

And I think it's one of the reasons why-- there's a number of reasons why we have the whole m dot infrastructure where people redirect you to a mobile site, and they actually give you a pretty good experience.

One, it's actually pretty hard to move across from a complete desktop site to an m dot site.

But the other is, they have two different types of customers and users that they have to deal with.

And we need to get away from this model where we have that baseline.

And it actually revolves normally, unfortunately, around IE 8 at the time.

So a huge number of developers I speak to who have actually made the jump, and they know they don't need to support it anymore.

I asked them, technically, how do you do it? And it's like, it ain't a technical solution, mate.

We raise our prices.

And I'm like, well, if you raise your prices, don't you lose customers, and it's an open market, it's able and can compete with you.

So that basically, if people can compete with you, you get beaten normally on a cheaper price.

And they're like, that's fine, I don't mind people beating us sometimes.

It's not the greatest experience.

But the thing that you have to remember is, IE 8 in this case for us, increases the cost of a build significantly.

And the thing about this, what they were saying was, obviously, it's not just all the extra development that they have to do, and the trade offs that they have to make on building experiences.

It's also to do with-- I'm trying to work out how to say this now.

It's also to do with all the test infrastructure, the build, and engineering stage phase as well.

So if you are building an application that works in IE 8, you have to have your VM set up, you have to test the as well.

It just adds a huge amount of extra complexity to any kind of infrastructure as well.

And the number of people I've spoken to said, actually, this works pretty well.

I can't say whether it does on a personal level, because I don't get paid to build sites, I pay people to do it.

So I'm in a slightly different situation.

But there's one point I want to try to make as well is, I know we've been talking about offline first, accessibility first, and a whole bunch of other stuff.

Accessibility is a really interesting point around this.

Because I was looking at some stats, and for my own errors, I couldn't find the source about this to actually put it in the slides, is that the number of people who have to use screen readers, and other accessibility aids to view the page, is roughly about the same level as Internet Explorer 8 users.

Yet, a lot of developers are not willing to drop IE 8 support when it's hard, yet they'll drop accessibility, because they haven't got enough time.

And I think that's actually a really, really bad place for us to be in an industry if we're doing that.

And, again, unfortunately, I don't quite know how to change that just yet.

But it would be good if we didn't have to be in that situation.

But again, obviously, I always say about this, we live in the real world.

And, obviously, it's up to you about how you decide to build these sites and actually offer services to the customers.

But my goal, and I'm going trying to talk about this is as a whole, is to try and get everyone to move forward in the browser level support.

Because once you understand that it's about modern browsers you can actually start to talk about features that you want off the users, rather than have to say, I have to retrospectively support all the browsers.

But we live in this real world, and you have to make that decision yourself.

But what I want to talk about now is the state of the web today.

This is what leads me to the headless web vision.

That's a far flung vision, but there's actually a very definite trend in the web industry.

And there's two people, people driving that at the moment, or three sets of people.

There's us, developers, depending on whether we have to respond to the clients.

Clients in general, they direct what we can build on the web, because, obviously, they pay our wages, and they have their ideas about the things that they want to build.

And unfortunately, they will be the ones requesting IE 8 support and everything.

And then there's browser vendors, the people who make the platform.

And that's what I want to talk about today is, the people making the platform have a very definite vision about where it should go.

And we as say, devrel and maybe the leading front-end engineers, we need to pull the rest of the industry along with us to actually change the expectations for users, and the expectations for our clients.

So we saw early on before, this is one of the first slides earlier on.

The pace of change of browser version is phenomenal.

Even if Internet Explorer and IE 6 only do one version a year, the difference between features that have come to the platform, and the increase in parity on the platform every year increases massively.

And it's only in the last four or five years that this has actually started to take place.

And I think this is really cool, and this is really powerful.

But we as developers, because there's a lot of stuff coming to the platform, we get lost quite easily.

And I want to show you how to navigate some of that at least.

So I've got this, this is my stats of browser usage.

And this is one of the things I use to try and convince people that, actually, where we want to be is not where this blue bar is here where the 91% reach of all users on the web, this is basically when IE 8 came out.

If you want to reach 91% of users, you have to target that blue bar.

And rather, I would actually try and get us to target the 2014 browsers.

Because, although we have 63% market share of leading edge browsers that were made in 2014, that was next to nonexistent in 2011.

So the idea is, that the pace of change in the industry is moving forwards to this rapid release model.

The industry is moving forward quite drastically to having pretty much everyone on a modern browser, even if it was made in 2013.

There are a couple of stalwarts.

Obviously, IE 8 is 4% of traffic, it was just there.

Does anyone with laser pointers, do you ever try and look at it to see how close you can get it to your eye before it hurts? No, I was doing this in the shower, not in the shower, but in the bathroom this morning with those two mirrors, and I want to see whether-- it doesn't matter.

Anyway, sorry.

I just thought that when I was looking at that.

There's two stalwarts, there's IE 8, and then there is the browser that we made.

And is for our ever eternal shame that we did this.

The Android browser was never auto updated.

It was only on, I don't know how to say this, it was only on-- the Android browser would only ever really get updated with more releases and updates to the platform.

So between 2.2, 2.3, 4, 4.1,

and all those types of things, you would get a new version of Android browser.

And this is really bad.

Luckily new browsers are on the platforms now, and there is default, like the always up to date ones.

Which is going to push that number in the far right up more.

But, unfortunately, we're just going to have to wait naturally for these to die, to die away.

And Android browser can actually increase your costs for development because of its foibles, and it's errors, just as much as Internet Explorer 8 can.

So, yeah, we need to do better as an industry, but the industry is moving towards that.

Those phones will go away, those phones are not getting made anymore.

People are on browsers, or starting to get phones now where they can be on capable platforms, and get the automated update all the time.

So I think that's actually pretty cool, and it's pretty powerful.

We're going to have to wait a year for that number to go up a little bit more, but it will go up.

And I said before, as a client, I commission websites, because we can't actually build all of our own websites internally.

Not technically.

I think we're all pretty good.

I hope we're all pretty good.

Jake, are you good at building sites? No, OK.

But we just don't have time.

We're a relatively small team, and we have to build sites, applications, and a whole bunch of other things.

And one of the things I've been doing in my contracts, is basically saying, we don't want to support IE 8, right? We don't want to support IE 9, even though it's got a pretty decent amount of usage.

We want to support the latest version of Chrome, Firefox, Opera, and Internet Explorer.

Minus one, so the previous version to get-- we don't want to use a brand new piece of functionality, essentially, that's going to completely break for half of the audience.

And maybe, n minus 2 as well.

And in this contract we said n minus 2 because it's a content site.

We wanted as many people to be able to read that.

But that actually gave us really good market share about the potential audience that we could reach.

I don't know how many customers that you deal with would be able to be in that type of model, but that's where I would like us to get to.

Like we can support the large majority of the web very, very well.

And that's how we should structure our contracts.

And actually, when we were building this, we built the site in about two weeks with the help of RGA, and then the content came through as well.

So we had a really rapid build, and it works really well across all devices, and all browsers.

But the thing I find really interesting, because I try to think in feature models.

Now this changed last night, or the day before, because we released a brand new version of Chrome.

But the idea behind this is, I tried to look at all the new features that come in, in the latest versions of browsers.

So in the olden days, it might have been the difference between IE 11, and 10, and 9.

But now it's the difference between say Chrome, 38, 37, and 36.

And as we can see, there's actually quite a lot of interesting things that come in.

And as we see in the far right there, the picture element, source set and screen orientation, these are things that were just missing from the platform.

They are now stable.

So in theory, we would get to about 30%-- well 52%, because 52% of the users are always on the latest browser.

But I look at the-- if you look at that now, in theory, 52% of the people would be able to use picture element.

That's not true, because I think it's only in stable Chrome at the moment.

But that's the pace, right? This changes every six weeks now.

The number of features that come in are pretty compelling.

And this is actually one of the ways that I look to see what I should be learning about, as someone in developer relations, so I can educate more people.

Is I look at all the features that are come in.

I look at n plus 1, n plus 2, to see where they're going.

And then I try and build a developer story around them.

And I think that's actually pretty cool for you as developers as well, because you always want to learn what is the next best thing that you should be looking at? What is the most important thing? But there is about 300 million different things that you should be focusing on.

And focusing on the order they come in the browser is actually not a bad way of thinking about it.

One of the things I wanted to talk about as well, and this is actually starting to get to the direction of the web platform, Dimitri Glazkov he's an engineer on Chrome, he did a post in about February to the blink-dev mailing list.

And he said, we need a sound component model to build a modern mobile web apps.

The Shadow DOM is the foundational part of such a component model, a.k.a.

Web Components.

And it aligns with Blink's priorities.

So you have to ask, what are Blink's priorities behind that.

If Blink is interested in build interactive books, magazines, the state of the web as we know it in the past, then we probably shouldn't be working on Shadow DOM.

And Dimitri always likes to cite his work as well.

Every single conversation he has a URL at the end of it.

But the point is about this, is that if you take this at face value, the browser vendors understand that applications are the future for us when we're building mobile web experiences.

Yes, we're still going to push forward on content based experiences, so we can get the glossy magazines side of things.

But you look at the technologies that are coming in to make it easier to build compelling mobile web apps.

Things like Shadow DOM, things like Service Worker.

Things like screen orientation, you know, the screen lock, you don't need that for a content site, you need those for applications.

And we're trying to do this work, and we're trying to push that platform into the whole mobile app space.

And there's a lot of work going into that at the moment.

I think that's one of the things, I'm never quite sure whether it's amazingly clear in the industry that's where we going.

I think it is pretty clear for me is that is where we're going.

So I found this actually pretty interesting.

I looked at the number of features that will come into the browsers.

This is Chrome, because there is just some oddities with time, and for the browsers as well.

2013 was a pretty quiet year for some reason.

I'm not too sure why, it might be a bug in my analysis.

But if you look at 2014, and 2012, 2012 we had index DB.

It's now probably a point where we could use it consistently for applications.

But you look at Shadow DOM, Audio API, cryptography, dialogue, will change, all these types of things.

Web animation, web animation is not necessary for apps.

But a lot of these features and capabilities are really best used in the context of applications.

And I think if you look at the way that the browser is going in terms of the features that are landing, you can start to understand the trajectory of where you're going.

So I think it's pretty cool.

Because we're all in an apps world, this is a shameless plug for my blog.

It's rubbish blog most of the time.

But I decided to try and work out whether I could live in a world of mobile web applications.

So I spent a day turning off all native functionality on my phone.

Notifications, push messaging, everything.

I basically said to myself I'd never use a mobile app for that day.

I'd like to see how I get on.

And it was kind of an interesting experiment, because it failed, I think is the easiest way of saying it.

So I tried to identify 10 deadly sins of mobile web applications.

So the analysis I did, I looked at all different applications.

Some applications work really, really well, I know we were talking about Twitter earlier on.

The Twitter mobile web application works really, really well.

You can use it offline, you can refresh the page and do a whole bunch of really nice stuff, and get access to tweets that you had.

There's apps like SoundCloud, and a bunch of other stuff that work beautifully.

And they look and feel amazing.

However, the majority of the web isn't made for mobile at the moment.

That's my biggest concern.

And we have done some analysis internally.

You're looking at about 60% of the web is mobile, so 40% of the web is desktop only.

And if you look at the number of applications, especially if you go and try and find mobile web applications, it's actually, one, it's really hard to find a good mobile web application at all.

We don't have a marketplace, and Google search absolutely sucks at finding applications.

But when you do find an application, it's not mobile.

And this actually presents a massive crisis of confidence for the web developers.

And we can't get found, we can't build applications which are compelling enough to go mobile.

And I worry that's one of the reasons why people actually go on the native platforms.

But there's a whole bunch of other stuff out there.

Some stuff doesn't look that good.

There's massive monolithic services.

I want to talk about two different ones which I think are important in the context of the future of apps.

One, is the ephemerality of everything.

And this is what we were saying before about Service Worker, is that right now, when you try and use any web applications, in most cases, you will use the application, and you'll do some work.

Like Twitter, say I use the Twitter web app and it was really nice.

I do a tweet, I go back, and I go back to doing whatever I was going to do.

I'd never get any notifications.

And I'm actually a pretty unpopular guy on Twitter, so I never normally get that many notifications.

But I was actually getting replies to a tweet, I didn't know I was getting the replies, because I got no update, no notifications that, actually, something had happened.

And that's because the browser doesn't live past the time I closed it.

Or the application doesn't live past the time I close my application.

And I think that's one of the things that Service Worker really gives us, is that we have the application lifecycle model.

We have the potential for our browser to live in the background, go to sleep when it needs to, but wake up and do some processing again once there's something interesting that's happened.

And I think that's only the start, right? Notifications, and those types of things are the start of the change that we're going to expect from web applications.

And we're going get to the point where web developers can go, I want my website, or my web application, to be ephemeral, never needs to be installed.

Or they can say, I actually want it to be able to be installed, and offer advanced services to the user.

And I think that's a really good position to be in.

I also looked at the number of features that we have on the platform.

And I tie this back to work I did, because I spoke to quite a few developers, native apps developers of the time.

And the first thing that they say is, the reason why we build native, one of the reasons why they say they build native, is that we don't have access to geolocation, camera, and touch, and sometimes the gyroscope.

And that's wrong, right? We do, we have all these APIs.

And they're pretty broadly supported, especially on mobile devices.

So we could build some really compelling applications with the web that we have now.

But when you look at a whole load of features that they don't talk about, like if someone is developing a game, so they'll have web gel, and web audio.

We've got pretty good support for that now on the web.

But you can't build a game on the web and expect users not to be really frustrated.

Every time you turn your phone, like if you're using a phone, every time you turn it, the screen does an orientation change.

So my thought here is, actually, we've got a lot of good features, just not always the right features on the web.

Things like screen orientation are a really good example of that, where it's an afterthought in most cases where-- I don't know.

What can I say? It's like an afterthought for the web platform developers.

It's like, we've got all these things, why aren't people building it? Oh, well, we need screen orientation.

So they come on later.

But this is changing, and I know this is changing a lot.

I know I'm being kind of hard on browser vendors, but we just don't have the compelling platform that we need.

Things like notifications as well, things like push messaging.

And offline as well, we just don't have good support for them on the web.

But it will change.

And then once it does change, we'll start to be able to build progressively better applications.

I'm definitely not alone in this.

Because I was like, I can't be the only person who's actually found this, and found all these frustrations.

If you go to the W3C, they've got mobile web app state document.

They basically have already done that in-depth analysis, so I didn't have to actually live with my one day of web apps and suffer from using that.

But basically, they understand that, to build a compelling platform that rivals native, then there's a lot of work that we still have to do.

We have to do payments, we have to be offline properly, we have to get push messaging notifications all back into the platform.

Some of the worry that I have is, that sometimes use a very high level abstractions and not meeting the same goals as the extensible web manifesto.

But, at the same time, is that we always understand that these are the things that we need to focus on, and the industry will change.

And I'm actually pretty optimistic about this.

So, in the meantime, one of the things I really struggle with is actually finding great quality applications, mobile web applications.

I've got about 24 or 25 of them.

SoundCloud is a good example of a great one as well.

This is my Tumblr.

I really would appreciate, if you know of a good mobile web application, is to send it through.

Because I want to make sure that everyone I know, knows about good mobile web applications.

Anyone who follows the Chromium-dev team on Twitter, we'll share these out through there.

People will start to know that there are good mobile web applications out there, even if the platform is not entirely capable.

I want to make sure that we, as a platform, don't just go, you know what, we can't build anything that's good, let's not bother.

I want to make sure that we have constant promotion of great experiences.

And, I think I'm getting close to the end now, which is kind of good.

There's a special chapter.

Most movies only have three acts, I've got four, because I'm not a movie director, and I don't know how to write scripts.

How do you stay one step ahead? Well, obviously, caniuse.com is great.

You'll be able to use all the tools in here to understand what is coming to the web platform.

To understand its history as well, which is really good.

So I definitely encourage everyone to go to caniuse.com.

I If you know of a mistake, just file a book request, and try and fix that as well, because it'll make everyone's lives easier.

And I think this is a really powerful site.

There's iwanttouse.com as

well, which is the one I built.

It's different caniuse, but it's powered by its same data.

This is off the idea that you're looking at features, and its level of browser support, so you know your entire feature set basically, so you can sell your service to the clients.

So we have that.

It's kind of an interesting tool.

This entire presentation was-- so the actual caniuse data is really good, but it's actually relatively hard to pass, because it's been optimized for the layout of caniuse.com

But all the information is there for you to analyze.

I've made a project called CLI, command line interface, caniuse, basically.

And the idea is, it's trying to give us a more robust API that's on top of caniuse.com data.

It provides some extra data, for instance.

So caniuse.com doesn't have

data around when something came to the platform, like a browser was launched on the platform.

Was Chrome 37 in 2014 or 2013? But I used all this API to actually generate all the data for this entire presentation today.

And it's basically a command line web application.

I would jump into it, but I'm not going to bother.

Essentially you can look at various eras of feature support, so it works on features.

So you can say, stats dot get era.

What is in the current modern era? As of today, was is on the web platform? And you can look at the previous eras of what has been on the platform.

You can look at the today, and then, basically it will give you that list of all the things that are on the platform today.

You can do some nice things like look at what's going to come in the future.

So caniuse actually tracks interesting specs that are coming out in the future, and that are getting worked on the browsers.

So you can actually say, well, what's in three versions ahead? What's in the next version of Chrome, in the beater version, that I should be starting to look at today? And it will give you the list of features.

The really great thing about this, actually, is that there's actually a lot more data behind it than features.

It gives you browser support, so you can work out roughly, if I use this feature, how many people will be able to see it? Oh yeah, what's new in the next generations? So the thing is, the get era stuff gives you a dump, gives you a dump of all information.

What you need to do is, you need to do some set theory to work out what is brand new to the platform.

So you compare the platform today to the platform known to be where we are going tomorrow.

And you can get a list of all the brand new features.

And that's where I got those three, like pictures, src set, and screen orientation from earlier on.

We can also, I use this a lot actually, I look for versions of Chrome.

So this is how I worked out all the features that were brand new in Chrome in 2014.

Is that I knew 33 and 38 were the first and last browser in 2014.

So you can work out, do a difference, what the state Chrome is, what features are actually brand new in 2014.

Likewise, you can also work out what's removed.

It doesn't normally happen, but SVG fonts was a good example of Chrome removing a feature.

You can understand that pretty quickly with an API call.

And you can also work out how browsers are similar.

So what features do we have in parity between, say, Internet Explorer 11, and Chrome 38.

And you'll get a good holistic picture of the feature set.

And likewise, how the browsers differ.

What are the things I can do because maybe Internet Explorer 11 doesn't work? So I think data makes us better.

And this is what I've been using to try and work out what I should be working on next.

If you have the data, you can predict the future quite well to some extent.

It's harder to predict the far future, which is why I might be completely wrong.

But I do think that the web is not going to be just in our browser anymore.

I think a lot of our interactions with it will be outside of the browser.

They will be in all the other touch points and service areas of the actual mobile phone, and the device.

So notifications, notifications on my watch, and all those types of things.

If you understand the past, you can actually better understand how you can adopt, sell your services to clients more effectively.

You can actually understand what features are supported when, and actually how to work around them.

So if you're going to go down the progressive enhancement route, you can actually understand that with a lot more intelligence about feature support.

And also, the potential reach, and the people who would be affected by your choice when you're making those pitches to the clients.

And if you're trying to understand now, I think that's actually pretty interesting.

Because the web is going towards apps, and then you can actually start to adjust the way that you learn about new features, and where the platform's going, by understanding, not just by looking at the data.

And, like I said, I don't actually think the front end is dead, even though I said it earlier on.

I think there's going to be a lot of competition between where the user actually starts to interact with our websites.

And I think it will start to come out of the browser a little bit more.

But people will expect great, compelling mobile web applications, and desktop applications still.

Even with those extra touch points that they'll have.

Yeah, I'm done.

Thank you.

Come over here.

Here we go.

You really scared me at the start when you said-- oh, thank you.

Yeah, you really scared me at the start where you said this is my last slide.

That kind of made me panic.

I thought I was going to have to talk to you for half an hour, and I wouldn't wish that on anyone.

Thanks, mate.

You kicked IE 8 a lot during that talk.

But you fairly glossed over the old Android browser.

No, I said it at the end.

It's easy to talk about IE 8, because that's the last major point.

After that, there is still the Android browser.

The Android browser just is screwing everyone over on the mobile web.

And the only way that we can actually get rid of it, unfortunately, is to buy newer devices.

And that will happen, it's just going to take a year or so.

But also, I was going to say, also, Android browser never comes into it.

When you talk to a lot of clients, people who are actually getting contracts from people, it's always IE 8.

That the minimum browser's got to be IE 8.

I actually think that is wrong.

We want to go to version support.

I want to go maybe two or three versions back.

And that was the point I was trying to make.

Not necessarily slam IE 8, which is maybe the way it came across.

No, but, I mean, in the real world, if we use IE6 as a baseline, we're going to be a lot of trouble in emerging countries, right? Where there's a lot of old Android devices still being sold-- Yeah.

Yeah.

[INTERPOSING VOICES] Android 2.3 was,

at one point, still the fastest-growing mobile platform.

I think that's changed quite a bit now.

I was speaking to someone, they were basically saying that, if you go to Bangladesh, every single phone that you try and buy now is at least an Android 4 phone.

Even if it's like a $20, $30, $40 phone.

So I think that's kind of interesting.

I think the tide is changing.

I want us to move away from having that minimum browser support, to be more holistic about the feature set that you want to target for.

So you were mentioning these background features.

So are we going to be installing websites, and it's missions, where do they come in on that? [INAUDIBLE].

No, I think there's a massive problem that we've got on the web where we have Add to Home Screen on iOS.

So that's the install idea.

It's really hard to find even on iOS now.

It was near impossible on Android browser, like you had to go through 17 steps.

Chrome made it easier, but Chrome is starting to hide at the Home screen.

So I think, at some point, we're going to have to make the case that users actually want to be able to install applications.

But to get there, to get to the point, is we need to make better applications to some extent as well, and get users using them over their native applications.

And this is a really hard point for us.

Because while the platform isn't there, I think there's a lot of stuff that we can start to do.

Namely, Service Worker in particular.

Maybe it's never installed via the Add to home screen kind of way of doing that install.

But there is some other permission problem that says, hey, this is going to live in the background, or do notifications, and live forever.

Are you cool with that? Yes.

And that's the install.

So you can have 10, 20, 30 sites installed that do push.

And they don't take up any extra resource.

So letting websites do stuff in the background, that's crazy, right? I mean, what are we going to do to stop bad players, bad actors, on the web? I think it's the browser, right, is going to essentially force-- so if you look at Android, and on the native platform, that native platform is pretty aggressive at killing off tasks which, not necessarily block, but would, if you lock the screen or do something like go to a different app, it just goes, you've got to go to sleep.

And that's the same model that you want to see in the web, right? If you're not necessarily the foreground application, you should probably be sleeping, but there might be some extra stuff that you have to do.

Like receive notification, do a background sync, and pull in data so the data is ready.

But the idea is that you should do that for a minimum of time.

And the browser can be very aggressive about killing things off.

Cool.

That's excellent.

Paul Kinlan, everyone.