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

EdgeConf - Progressive Enhancement

EdgeConf - Progressive Enhancement

Remy Sharp

June 27, 2015
Tweet

More Decks by Remy Sharp

Other Decks in Technology

Transcript

  1. Progress Enhancement
    EdgeConf Panel 2015

    View Slide

  2. In 2003…
    …structure geared towards
    the lowest common
    denominator.
    2003 - Steve Champeon (on Webmonkey) coins the term “progressive enhancement”.
    Documenting the current approach of graceful degradation, and suggesting the process should aim to structured towards the lowest common
    denominator.
    There’s no specific definition, which might also be why there’s some movement around the idea…
    There isn’t actually a definitely in the post, and wikipedia suggests “progressive enhancement allows everyone to access the basic content and functionality
    of a web page, using any browser or Internet connection”.
    Different from graceful degradation - which would handle failing browser support, i.e. with a noscript tag

    View Slide

  3. How would it work
    without JavaScript?
    ¯\_(ツ)_/¯
    I ran a very focused survey where I asked my twitter followers to answer a few questions, and share the survey.
    My followers (are likely) to share my own sensibilities. However, 25% of 800 people who answered, said that PE is “works without JavaScript”.
    Also: who the fuck turns off JavaScript? They don’t - it might not come down the wire it might be broken - checkout Stuart Langridge’s flowchart (I’ll
    tweet a link)

    View Slide

  4. You know the story. No JavaScript and the page is totally blank. Though, I’m not sure what’s worse: blank or “this page requires JavaScript enabled…”.
    This is Talky.io - absolutely superb service (go back them on kickstarter), that uses WebRTC for chat. WebRTC is entirely JavaScript based. How would that
    work???
    Okay, it’s too hard, let’s give them a pass…

    View Slide


  5. Instagram. A *photo* web site. With pictures. That’s all. I’m not sure what it would take to make this work without JavaScript…
    …boom - oh yes, and image tag.
    Okay, so that’s a big company, owned by Facebook, using the React JavaScript library - we’ll come back to that.
    What about if we tried a web site by a developer that has a strong understanding of standards? Like the Mighty Mr Appcache Jake Archibald…

    View Slide

  6. This is me using the superb tool SVGOMG…with JavaScript disabled…
    Nothing is clickable. At all - not even the link at the bottom. As you can see, I’m very disappointed…

    View Slide

  7. Without JavaScript?
    “each phase of the
    enhancement needs a user”
    Jake said in an interview about SVGOMG “I’m a strong believer in progressive enhancement,
    but also that each phase of the enhancement needs a user. Working without JS benefits older browsers, but as a site targeted at developers I figured I could
    safely leave older browsers behind.”
    This is key. SVGOMG does progressively enhance, and polyfills where functionality is missing.
    http://paulrobertlloyd.com/2015/03/svgomg/

    View Slide

  8. ...figuring out what
    is core functionality
    and what is an
    enhancement.
    Jeremy sums up PE beautifully with that it’s not that everything has to work without JavaScript, but “figuring out what is core functionality and what is an
    enhancement.”. Exactly what Jake did, and what PE is about.

    View Slide

  9. How do we re-frame
    our thinking towards
    progressive
    enhancement?

    View Slide

  10. Thick clients
    What is the
    JS framework story?
    Angular, for instance, does not have a developer story for how to develop a site with progressive enhancement as a baseline.
    Does this mean it's not possible? I don't think so. Without the stories though, developers will gravitate towards solved problems (understandably).

    View Slide

  11. Web Components
    Web Components are a hot debate topic. They could cause all kinds of mess of the web. On the other hand, they're also a perfect fit for progressive
    enhancement.
    Take the following HTML:

    View Slide

  12. type="text"
    name="creditcard"
    autocomplete="cc-number"
    required>
    Notice that I'm not using the pattern attribute because it's hard to match correctly to credit cards (they might have spaces between groups of numbers, or
    dashes, or not at all).
    There's also no validation, and the first number also tells us what kind of card is being used (4 indicates a Visa card for instance).
    A web component could progressively enhance the element similarly to the way the browser would natively enhance type="date" for instance.

    View Slide


  13. type="text"
    name="creditcard"
    autocomplete="cc-number"
    required>

    Notice that I'm not using the pattern attribute because it's hard to match correctly to credit cards (they might have spaces between groups of numbers, or
    dashes, or not at all).
    There's also no validation, and the first number also tells us what kind of card is being used (4 indicates a Visa card for instance).
    A web component could progressively enhance the element similarly to the way the browser would natively enhance type="date" for instance.

    View Slide

  14. Are web components
    the future of
    progressive
    enhancement?
    I wonder, are web components the future of progressive enhancement?

    View Slide

  15. Potential problems
    on the horizon
    Developers are inherently lazy. It's what makes them/us optimise our workflows and become very good at solving problems. We re-use what's known to
    work and tend to eke out the complex parts that we can "live without". Sadly, this can be at the cost of accessibility and progressive enhancement.
    I think there's some bigger potential problems on the horizon: ES6 - esnext (i.e. the future of JavaScript).

    View Slide

  16. ES6…esnext
    "But progressive enhancement has nothing to do with ES-whatever…"
    Taking a step back for a moment. Say we're writing an HTML only web site (no CSS or JS). But we want to use the latest most amazing native email
    validation:

    Simple. But...what happens if type="email" isn't supported? Well, nothing bad. The element will be a text element (and we can validate on the server). The
    HTML doesn't break.
    JavaScript isn't quite the same, but we can code defensively, using feature detection and polyfills where appropriate.
    ES6 has features that breaks this design. Syntax breaking features that cannot exist alongside our ES5 and cannot be polyfilled. It must be transpiled.

    View Slide

  17. =>
    No, not an emoji!
    There's a small number of ES6 features that are syntax breaking, the fat arrow in particular.
    This means, if the arrow function is encountered by a browser that doesn't support ES6 arrows, it's cause a syntax error. If the site is following best
    practise and combining all their JavaScript into a single file, this means that all their JavaScript just broke (I've personally seen this on JS Bin when we used
    jshint which uses ES5 setters and broke IE8).
    I've asked people on the TC39 group and JavaScript experts as to what the right approach here is (bear in mind this is still early days).
    The answer was a mix of:
    Use feature detection (including for syntax breaking features) and conditionally load the right script, either the ES5 or ES6
    Transpile your ES6 to ES5 and make both available
    This seems brittle and the more complexity the more likely that as time goes by, new projects will leave out the transpile part, and forget about supporting
    older browsers - or even newer browsers that don't ship with ES6 support (perhaps because the VM footprint is smaller and has to work in a super low
    powered environment).

    View Slide

  18. Is there a workflow
    that solves this?
    Since JavaScript doesn't exhibit the same resilience that HTML & CSS does, so the fear is that it'll leave users who can't upgrade, faced with a broken or
    blank page.

    View Slide