Upgrade to Pro — share decks privately, control downloads, hide ads and more …

This is the Web Platform

This is the Web Platform

An analysis of the trends in the web platform to help you plan, prepare and build for a better web. We'll go into ways to analyse trend data to help you learn more effectively about the platform, and we'll go into tools you'll need to make intelligent decisions when deciding on feature levels and browser support.

Paul Kinlan

October 12, 2014
Tweet

More Decks by Paul Kinlan

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. it’s all about apps
    They tell you everything you need to know about the movie in the first 5 seconds.

    View Slide

  5. the frontend is
    dead
    The spoil the ending

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  64. The frontend isn’t dead

    View Slide

  65. Credits
    Paul Kinlan
    [email protected]
    @paul_kinlan
    +PaulKinlan
    paul.kinlan.me
    as himself
    as his email address
    as his twitter account
    as his g+ profile
    as his web site

    View Slide