This is the web platform

Happy
Birthday
Jack
I nearly never made it to Fronteers, It’s my son’s birthday today. Actually it turns out I don’t know my son’s brithday, it is tomorrow. But he did ask me to ask
how do you say Happy Birthday in Dutch, so I would be honoured if you could all tell me. After 3.......

Paul Kinlan
presents
@Paul_Kinlan
in
This is the Web
Platform
Because we are in a beautiful 1920’s cinema I have tried to theme this like a movie. Like all good movie trailers there is an action shot of the main
protagonist...

TLDR;
it’s all about apps
There is a hint of a love story

They tell you everything you need to know about the movie in the first 5 seconds.

the frontend is
dead
The spoil the ending

Time for questions?
So know we know everything, Jake would you like to come up and do the questions.

there is a change coming...
There is a significant amount of change coming to all of us and we will all have to adapt to the way that we build for the web.
There is a reason why I do what I do, I help educate developers on the platform and how to deal with it in the real-world
I believe that every app and piece of content should be built for and hosted on the web. However developers aren’t building for the web we have
today, they are building for the web we had 4 years ago. Ideas that we seed now are not getting picked up by the majority of developers until 2
years after they land in the browser...

Year 00 03 06 09 12 14
IE 5.5 6 7 8 9 10 11
Firefox 0.7
0.8
0.9
0.10
1
1.0.1
1.0.7
1.5
2.0 3 3.5 3.6
456789
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Chrome 1 23
45678
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
Safari 1 2 3 3.1 4 5 5.1 6
6.1 7 7.1
Instead of every two years, browsers for the majority of users are getting updated automatically every 6 weeks, so how do we deal with this 8
change.

this is the web platform
what was
what is
what will be
This is the web platform. a story about the of the web, where we have been, where we are today and where we as front-enders should be
investing our time for the future, today!. We live in a time of unparalleled change on the web and this story is designed to help you navigate that
change and build better apps and sites.
And like all good Quentin Tarantino movies, the order of this presentation makes no sense.

what will be
Chapter 3
What will be, the future as I see it. It starts with murder!

APP CACHE ASSASSINATED
IN COLD BLOOD
violence and wanton
carnage.
Witnesses report seeing a
slightly balding ghostly pale
man in his late 30s running
away from the scene. The
motives are as yet unclear,
but it is suspected that the
victim is well-known to the
perpetrator and there is bad
blood between them.
PRONOUNCED
DEAD ON
ARRIVAL
Two gun shots were heard in
the vicinity of Old Street in
London at 6am this morning.
Police attending the scene
reported an horrific scene of
needless Eyewitness photo fit. Have you seen this man?
App Cache is dead. Assassinated by a young punk, believed to be one Jake Archibald. Reports said that there was a lot of swearing, someone
called someone some names. We believed that it would solve all of our problems, we thought that to make a great app we needed to make it
work offline, but this was not the case, it was lazy it forced web developers to change how we build apps. Offline is the first step on a long road
to making the web a comprehensive app platforms. And AppCache is not the answer

SeWrviocerker
It took a while, but there is a revolution happening with people like Jake, Alex Russell and many others pushing the idea of service worker and it
preaches models that web complements web developers workflows and progressively enhances advanced features in the browser, but will
fundamentally change the way we expect our applications to work. There are at least 3 key areas that they want to change about the web.
github.com/slightlyoff/ServiceWorker

Installed
Running
Sleeping
Uninstalled
Activated
Redundant
Every app should
have a lifecycle
Previously there was the ephemeral web, only two states: Page Visible, or dead. We believe that now, every page should have an app-life cycle
if you want it and it should be able to live in the back-ground.Once it is living in the background you can start to do really interesting things

Every developer should have control over
the app stack
fetch push message
install sync geofenceenter
You should have full control over your web page, you should be able to manage every request and decide what to do with it, should cache it,
should you serve a different version. You also get to intercept every push message or message from another application. You should have fined
grained access over for all aspects of the stack.

Synchronisation
Make your own
AppCache
Inter-app
communication
You should be able to build
higher level API’s on lower
level primitives
Parallax
Scrolling...
When you have control over the lower levels of the stack you can easily build higher level API’s. For example you can re-implement the best bits
of AppCache by intercepting and manipulating the requests that come in and out of your site. When an app lives in the background and can be
invoked we can easily build a Web Intents like API platform inside your own application without the need for the platform to support it. Finally, by
being able to receive push notifications of changes you could build a solid synchronisation framework without having to rely on something directly
built it to the browser. So where do I think this is leading our browsers?
extensiblewebmanifesto.org

The Headless web
We all know about Headless WebKit and Gecko through tools such as PhantomJS and Casper.
Even at Google this is how we inspect some pages, we load them up in a browser and analyze the content as it would be displayed in a browser.
The data and the content is never seen by a users browser.
Now take this a step further, now that the web has a way to live in the background, respond to the system and interact with the user, do we even
need a user visible surface any more? The browser is the runtime, the rendering engine is just one small part of that stack, one part that I believe
if we want to compete with native platforms we are going to have to remove our reliance upon.

Notifications are a prime example, the site or service worker generates a notification on your phone which manages and synchronises the
messages between your phone and watch. What happens when you click on it? In this case it might open a page on the phone, however on the
Android platform they are pushing actions to occur, you swipe left and you get some contextually aware actions you can take on the data. The
browser might never be visible, but the runtime is what powers this.

google.github.io/physical-web/
The Physical Web project is another great example of this. BLE beacons that constantly broadcast a URL and when your device detects this after
a scan it presents the contents of the page to the user in a surface that is not the browser but has been rendered from content that we as front
end developers control.

Google Now is another example along with Siri, it takes a lof data that is on the web and makes a new frontend out of it. But how do you control
this, well that depends, but schema.org markup is one example. As a front-end web developer you going to have to learn about all these new
surface areas for your content and interaction, it is not going to be native developers that do this.

Instead of every two years, browsers for the majority of users are getting updated automatically every 6 weeks, so how do we deal with this
change.

WANTED
DEAD OR ALIVE
For killing the web as we know it
If you are a normal front-end developer this is the person you want to capture, you want to stop him and the gang that he is in from building
service workers. He is still at large, if you see him. Stop HIM!
www.flickr.com/photos/robertnyman/5756323934/

What do you want the
web platform to be?
So, what is the web for? Is it documents? Is it web apps? If it's web apps let's assess how good the platform is...

what was
Chapter 1
So the big question is, these are new API’s and features that are landing almost monthly, how am I supposed to be able to keep up, learn these
new features and then integrate them into my services so that I can build better apps and sites for my customers and how do I deal with the fact
that I need to support IE. All good stories start with a love story.

TLDR;
Love between a handsome, dapper young gentleman and a website... no, that’s not right. Caniuse.com is an amazing resource for learning what
features are supported on each browser and looking back to when it was supported. But how do we as developers get a look at the bigger
picture, how do I know the what features I can use more holistically.

It’s not the site I love
It’s not the site that I love, that is a good friend, but it is....

It’s the data
data.json
the data. there is a huge amount of deep analysis and learning you can gain from this data. And my entire presentation is built of this data,
because when you know what was, you can predict with a high-accuracy what will be. And once you know what is coming you can prepare, you
can invest your time in selling your skills to customers, build better sites for them and push the web forward for your users.

iwanttouse.com
We live in a world where we have to deal with the minimum browsers and that has to change. Customers use their stats to work out where the
smallest meaningful section of their customers come from which ultimately dictates the experience we as web developers can build. So I built a
site to give you tactical guidance on features that you can use and when so that you can better sell advanced web experiences to your clients.

we are stuck in a
world of IE <= 8 We are stuck in a world where IE8 still represents the baseline experience that many developers deliver. I was talking to a company in the UK
recently that didn’t go mobile because 10% of their revenue was from IE8 and they couldn’t let that level drop. This is a serious problem because
it means as you grow your customer base you have to also grow your IE8 base. This is one extreme example of the worst possible outcome,
rather than accelerating revenue on leading edge browsers and naturally letting IE8 become a smaller and smaller fraction of their gross.

15 features are
ubiquitous Let’s consider 8 as a minimum, it means that we get roughly 15 features available to us on all platforms going back to IE8.
That is pretty pretty bad. Obviously we can use progressive enhancement to add features in, but even now developers still are getting pressured
to offer the same experience across all browsers when this is not possible and is not the mandate of progressive enhancement and it leads is into
delivering sub par experiences.

Take a 4% drop
in reach
if you start thinking of the features that you need in any given project you can make some intelligent choices about the apps you want to deliver
and you can get away from having contracts that mandate IE8 support.
For example if you take a 4% drop in reach you get a plethora in new features available to you. If you take a 10% drop in browser support we
suddenly have a huge huge range of capabilities at our disposal.

onmobile.iwanttouse.com
We are in a world
where mobile is
But we live in a world that will be dominated by mobile.
I also created a the ability to look at the mobile snapshot (which by all accounts in 23% globally, 60-70% in places like India). But this presents
us with an interesting problem that we are starting to see....
king

It opens up a new
base line
We can’t have two
base lines
Mobile opens up a complete new baseline with more features that are more compelling to users who expect a better experience, but we can’t
have two base-lines. If we have to deal with base-lines, then we should be aiming for mobile, specifically mobile within the last two years because
that is where the growth is and also the sanest platform for us to build upon.

Raise your prices for
IE8
More and more people, they have to engineer, test and debug for IE and this is recognised as a significant cost... However it is an open market
and in most cases someone will undercut you, so you need to arm yourself with data to present to the client when their demands stop you from
delivering a great experience. It is crazy in my mind that we freely support a browser that has the same number of users that require
accessibility tools, yet we often forget or leave out accessibility as a nice to have

what is
Chapter 2
We live in the real-world. What is the state of the web today and where are we heading as an industry? It generally falls into two areas, where
browser vendors are taking us and what the industry (our clients) think it is going. You can have a lot of direction over clients, so I want to
present to you where browser vendors are taking us.

Year 00 03 06 09 12 14
IE 5.5 6 7 8 9 10 11
Firefox 0.7
0.8
0.9
0.10
1
1.0.1
1.0.7
1.5
2.0 3 3.5 3.6
456789
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Chrome 1 23
45678
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
We saw earlier that the rate of change across nearly all browsers and this is great for users and developers. This presents us with a massive
opportunity.
Safari 1 2 3 3.1 4 5 5.1 6
6.1 7 7.1
8

Year 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14
IE 0.18 0.10 3.96 2.4 2.3 7
Firefox 0.06 0.02 0.11 0.18 0.53 0.76 11.8
Chrome 0.06 0.28 0.67 1.89 38
Safari 0.1 0.8 0.63 0.97 1.75 7.4
Other 1.7 1.94 5.84
Total 0.18 0.1 0.06 4.08 0.97 3.49 6.17 13.34 63.04
The Blue bar is the minimum bar set by IE. But as you can see from the Evergreen area the tide is turning, the vast majority of users are on a
browser that auto-updates, we have two significant chunks (IE8 users) and Android Browser that doesn’t auto-update (iOS too but they are
pretty good at shifting people to the new OS).
Cumulative 91.48 91.3 91.25 91.25 91.15 91.15 91.09 87.01 86.04 82.55 76.38 63.04

Year 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14
IE 0.18 0.10 3.96 2.4 2.3 7
Firefox 0.06 0.02 0.11 0.18 0.53 0.76 11.8
Chrome 0.06 0.28 0.67 1.89 38
Safari 0.1 0.8 0.63 0.97 1.75 7.4
Other 1.7 1.94 5.84
Our goal as an industry should be to get to 2014 browser or an evergreen browser,
preferably as far right as possible as our minimum bar because this is when it gets
interesting and browser vendors either moved in to an Evergreen model or they more
aggressively push out updates to their users.
We are quickly moving towards an evergreen model. To get there quicker we need to
get people off older browsers and we can tell companies not to ask for IE8, but really we
need to convince them that we can build better experiences that ultimately lead to more
revenue.... the problem is that no one is talking about it.
Total 0.18 0.1 0.06 4.08 0.97 3.49 6.17 13.34 63.04
Cumulative 91.43 91.3 91.25 91.25 91.15 91.15 91.09 87.01 86.04 82.55 76.38 63.04

N-2 GOOD
N-1 BETTER
For example, as a client, in recent contracts and projects we have been running, we have asked for N-2, that our minimum bar experience is the
latest version - 2 versions. That is the latest version of browsers back one version. However this doesn’t really help you because N-1 could be a
browser 2 years old so in this case we normally lock it to latest IE etc, but it does give you a sense of the capabilities of the platform. When you
consider this space N-1, N-2 it’s interesting to think about where the browser vendors are taking us. So let’s dive in to that.

N - 2 N - 1
caniuse.com/usage_table.php
N
77% 71% 52%
shadowdom
stream
rellist
deviceorientation
jpegxr css-backgroundblendmode
font-loading
font-feature css-variables
will-change
woff2
web-animation
imports
css-touch-action
font-unicode-range
pointer
cryptography
css-sticky
dialog
css-mixblendmode
css-shapes
N + 1
0.1%
picture
src-set
screen-orientation
I find it interesting in this model because you can look at all the features that are starting to make their way to the web. In this case, the picture
element shipped to 30% of the web yesterday and demonstrates how much the platform shifts underneath your feet, but at least it is in bitesize
chunks. Now something interesting, a huge number of these features are ideal for apps. So I want to shift gear again a little bit

We need a sound component
model to build modern mobile
apps.
I was inspired by an email Dimitry Glazcov an engineer on Chrome. And he said.

Shadow DOM is the
foundational part of such a
component model (aka Web
Components), and so it aligns
well with Blink priorities.

If Blink was primarily interested
in building amazing interactive
books and magazines in 2014,
it's less clear that Shadow DOM
would be worth working on. (Feb
2014)

goo.gl/bbp7vN
Dimity always cites his work. If you take this at face value, browser vendors such as Chrome believe that the web needs to become more App
like. Shadow DOM was just one part of that Dimitry was talking about, ServiceWorker is being introduced to give you the chance to build apps
that can take advantage of the underlying system and work a lot more like you would expect an app too.

2011 2012 2013
86% 82% 76%
border-image css-boxshadow
use-strict
fileapi
websockets
form-validation
details nav-timing
getcomputedstyle
download
getrandomvalues
indexeddb webgl
webm wordwrap
notifications
datalist touch
blobbuilder
bloburls
requestanimationfra
me input-color
contentsecuritypoli
cy webp css3-
tabsize webvtt
high-resolution-time
user-timing
resource-timing
css-featurequeries
flexbox
object-fit
mutationobserver
canvas-blending
vibration
css-supports-api
2014
63%
css-animation
shadowdom
matchesselector
audio-api svg-fragment
cryptography css3-
cursors-newer
dialog css-backgroundblendmode
srcset will-change
css-shapes picture
woff2 web-animation
imports css-touch-action
I found this interesting, so I did two things, I looked at the features landing in Chrome per year and I it looks pretty compelling, noted that a huge
number are focused on Apps. I decided to look at how well we as developers are utilising these features.

With this in mind, and my belief that we should build and deploy all applications via the web and have the browser as the runtime. I spent a day
living with just mobile web apps and it was pretty clear that as of today there is a lot to do.

10 Deadly sins of mobile
web apps
Lack of Focus Not mobile No Discovery Not
interconnected
Monolithic Authentication Slow and Ugly White screens
?
?
There are at least 10 areas where we get it wrong on the web, especially if we want to use our platform as the App platform for all users. There
are some simple things such as Developers are still not building for Mobile (40% of sites at my last count are not mobile), it is slow out there and
ugly. But there are two areas that I want to dive in to.

Everything is ephemeral
This is great for a lot of experiences; I pick up a site use it once and I am done. There are a huge number of apps — all communications apps for
example — where I need the app to live in the background to be able to deliver notifications but they can’t. We need an API, like ServiceWorker,
to help us and right now this doesn’t exist and it fundamentally needs to.

Geolocation 95%
Motion 87%
Touch 84%
Camera 63%
Notifications
Push
Offline
The platform has a lot of
Sync
features, just not the right
The list goes on.
ones The platform has a lot of many great features, just not the right ones to compete with the native platform: For example we have webgl and web
audio but you couldn’t build games because lack of full screen or screen lock. Likewise features you need to compete with native Notifications
and Push Messaging were greatly missed.

I am not alone in this, the W3C have identified a huge number of critical areas. However a lot of these in my opinion are high-level specifications
for specifications sake, what I would really like to see is a framework that gives us access to the primitives of the platform that ultimately let me
build higher-level abstractions on top of that. That framework could be Service Worker.
www.w3.org/Mobile/mobile-web-app-state/

mobilewebappsftw.tumblr.com
In the mean time, I am also trying to help solve the discovery problem by collating all the great mobile web apps so that we can build a great list
of patterns that we can use to educate developers on how we want the web to be built.

Staying one step
ahead
Chapter 4
The most important question for a front-end engineer is what should I learn... I could tell you specifically, but I would rather give you the tools and
resources to do it yourself.

caniuse.com caniuse.com’s data.json is an amazing piece of information, it’s not always 100% correct as we heard yesterday, nor is it exhaustive, but it is a
great tool and I have been trying to build a library on top of it to make is easier to access interesting information that you can’t get via the web site
so that you can use it more effectively.

iwanttouse.com
I want to use lets you look at the platform as a whole and make tactical decisions about how you message feature support to your clients and
how you can use certain technologies in combinations with others.

github.com/PaulKinlan/cli-caniuse
caniuse.com’s data.json is an amazing piece of information and I have been trying to build a library on top of it to make is easier to access
interesting information that you can’t get via the web site.

Here is a quick example, it is a simple web app that loads in the data from caniuse and allows you to do interesting things with it.

> var today = stats.getEras([0]);
> Object.keys(today);
All that is available
today?

> var soon = stats.getEras([3,2,1])
> Object.keys(soon);
All that is available in the
next generations?

> var today = stats.getEras([0]);
> var soon = stats.getEras([3,2,1]);
> Object.keys(__.difference(soon, today));
What is in the next
generations?

> var features = stats.getFeatures();
> var m38 = features.chrome["38"];
> Object.keys( __.difference(m38, m33) );
Features in 2014

> Object.keys( __.difference(m33, m38) );
Removed in 2014

> var ie11 = features.ie["11"];
> Object.keys( __.intersect(m38, ie11) );
How are browsers
similar?

> var ie11 = features.ie["11"];
> Object.keys( __.difference(m38, ie11) );
How do browsers
differ?

Data makes us better
Data makes us better. We can Predict the future. The web will not just be in our browser anymore, our front-end skills are going to have to adapt
to other surfaces. Understand the past. The data gives you insight into how you can make tactical decisions for your customs to build better sites
that work in more places. Understand now. We are moving to a world of web apps and vendors are making a large push in this area.

Credits
Paul Kinlan
paulkinlan@google.com
@paul_kinlan
+PaulKinlan
paul.kinlan.me
as himself
as his email address
as his twitter account
as his g+ profile
as his web site

This is the web platform

More Related Content

Similar to This is the web platform (20)

Recently uploaded (20)

This is the web platform