Edge Conf: Progressive Enhancement
Notes from the progressive enhancement panel at Edge Conf.
In 2003 the term progressive enhancemnt was coined but there was no strict definitioin, this is why "it depends" is such a common response. It may not just be "JS disabled" - there are many points where JS can become disabled. Blank website without JS hall of shame. Each phase of enhancement needs a user. Figure out what is core functionality and what is an enhancement. Thick clients don't have a user story for progressive enhancement. Web components could be perfect for progressive enhancement. Developers are lazy - the difficult parts tend to fall away when we head for the solution. Browsers don't break if we give it new HTML but ES6 has syntax that will break in an ES5 browser - we 've essentially disabled JS for our users. What about new browsers that don't exist yet?
The root of the problem is that we've drummed into people that PE means JS disabled. Developers like things to be binary so PE seems difficult. Focus is on JS because the wider focus on JS - it's not just about JS, it's the full stack. Turning off JS is a good proxy for was the site built with assumptions that it will always be running in the best conditions.
We assume that every user wants to use the full capabilities of their device - we're losing sight of the user.
Feature detection isn't going away soon. Client hinting to the server could allow the server to send the right code. Cutting the mustard is a good technique and should be focussed on the features you are using - not just as a proxy for browser detection. There is always the issue of browsers lie about what they support - worst case. Feature detection is getting much easier in browser.
We're introducing new syntax in JS that won't be able to be parsed in older browsers. There is a difference between this feature has been implemented and this feature has been implemented correctly. Relying on transpliers is a mistake for the web - most of the web doesn't use this level of tooling. We did this with ES3 -> ES5, transpilers help us move forward until we can cut the mustard to not need them. We used to use HTML comments in
<script> tags, we moved on from that.
Tooling is getting to be a barrier to entry.
Hell no, there is no common baseline. How low can you go? You know your audience, make assumptions but make sure you test your assumptions. Not every service will have the same audience but be aware that your audience will change. The less assumptions you make then the more future friendly you will be. What's the core functionality of what our product needs to do? If you don't have an audience then where do you aim? Accessibility is a good baseline but we have to make sure we don't nuke that with advanced technologies. Focusing on assitive technologies can be harmful to accessibility. Assitive technology is not the same as accessibility. Accessibility - the clue's in the name.
Just because a device support the API doesn't mean that it can run it very fast - CPU or network are both bottlenecks. You have to be practical - sometimes you have to use the user agents. Map UAs to features. Performance and resilience are also key features for progressive enhancement. If anything breaks then it should still deliver the core content.
We don't have a means of querying about the hardware - we could have the latest version of Chrome running on an older and cheaper Android phone. Once stuff has got to the device we can deal with it going to shit - we don't have a way of knowing that up front.
If we are going to make assumptions then assume the worst. Agressive enhancment: just nope out early.
PE is an unclear term - it's so contextual. We like the idea of server side rendered JS because we like new and shiny things - PE's been around for ages so it's not trendy. People want to do do PE but don't like its image. Isomorphic describes the developer benefit not the user benefit. Isomorphic is a technique, PE is a mindset. PE can change throughout the user's interaction.
PE seems like it takes more time. Like RWD and accessibility it takes time at first - once you're doing it there is no overhead. Don't sell it as an add-on.