EdgeConf - Progressive Enhancement

Transcript

1. Progress Enhancement EdgeConf Panel 2015
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
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)
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…
5. <img src=cat.jpg> 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…
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…
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/
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.
9. How do we re-frame our thinking towards progressive enhancement?
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).
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:
12. <input 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.
13. <stripe-cc-card> <input type="text" name="creditcard" autocomplete="cc-number" required> </stripe-cc-card> 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.
14. Are web components the future of progressive enhancement? I wonder, are web components the future of progressive enhancement?
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).
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: <input type="email" required> 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.
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).
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.