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 This is the Web Platform @Paul_Kinlan presents in 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

it’s all about apps 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 4 5 6 7 8 9 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 2 3 4 5 6 7 8 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 8 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.

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.

Chapter 3 what will be 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

Worker Service github.com/slightlyoff/ServiceWorker 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.

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

push fetch message geofenceenter install sync Every developer should have control over the app stack 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... extensiblewebmanifesto.org 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?

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 www.flickr.com/photos/robertnyman/5756323934/ 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!

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...

Chapter 1 what was 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; it’s all about apps 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....

data.json It’s the data 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 king 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....

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

Chapter 2 what is 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 4 5 6 7 8 9 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 2 3 4 5 6 7 8 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 8 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.

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 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 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).

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 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 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.

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 - 1 N - 2 caniuse.com/usage_table.php N 52% 71% 77% 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.

2012 2011 2013 76% 82% 86% 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 Sync The list goes on. The platform has a lot of features, just not the right 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.

www.w3.org/Mobile/mobile-web-app-state/ 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.

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.

Chapter 4 Staying one step ahead 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"]; > var m33 = features.chrome["33"]; > Object.keys( __.difference(m38, m33) ); Features in 2014

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

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

> var features = stats.getFeatures(); > var m38 = features.chrome["38"]; > 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.

The frontend isn’t dead

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