EdgeConf - Progressive Enhancement

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