Do we still need Progressive Enhancement in web apps?
There has been a heck of a lot said about PE in the last month or so, most notably from my favourite super-smart thought leaders, Jeremy Keith and Ethan Marcotte about the need to remember the lessons of the past, and keep progressive enhancement a key concern in one’s daily development cycles.
It’s a good thing to keep front of mind, especially when (to my mind, deliberately inflammatory) articles about PE being dead gain traction and encourage what I would consider a step backwards in that aspect of web development.
It’s an important question to ask, however. Why, when we have a proliferation of amazing JS web-app libraries that allow us to do magnificent things in the browser should we have to develop the same application twice? We live in a world where screen reader JavaScript penetration is 97.6%, and one of the Big Four browsers doesn’t even allow users to easily turn off JavaScript.
Why should I have to develop (and pay for) an app that renders once in HTML, before being overwritten by the same app written in a different language?– Recalcitrant Crowd of Developers
Does it take a lickin’ and keep on tickin’?
Of the 3 main aspects of front-end development, HTML, CSS, and JS, JavaScript is by far the most fragile. HTML (especially HTML5) handles malformed structure in a reasonably understandable way. CSS silently chooses to ignore rules it doesn’t understand. JS needs feature detection. Drop in an unchecked document.getElementsByClassName into anything less than IE9 and, well, the results may yeild unexpected results. Heck, forget to add a semi-colon to the right place, a dependancy fails to download, accidentally redefine a variable; JavaScript packs up and goes home at the first sign of trouble.
PE is not just about feature detection. It’s about ensuring that when parts of the site is broken, can other aspects still function. In other words, the parts of a site that do not cut the mustard in a browser shouldn’t cause the entire site to become unusable.
Christian Heilmann uses the ‘escalators and elevators’ analogy. When an elevator breaks down, it’s broken and useless. When an escalator breaks down, it becomes a staircase; still useable, just without the extra polish it had before. That’s how we should develop our sites. Embracing the meaning of PE ensures that we can be confident that when (not if) things go “kaka” it should function to some extent.
“Not supported” !== “Ignored”
One of the big points I took away from Jeremy’s post was that “The web is not a platform. It’s a continuum”. From Ethan’s it was that in this business “we play the long game”. Browsers do not pop out of existence the moment we stop supporting them. They’re still out there, used by certain demographics for various reasons, and they still require access to your content.
Development time costs. If it didn’t we’d probably end up “supporting” all browsers ad-infinitum. At some point, however, the project purse-holder will decide that it’s not worth the time and effort required to support a particular browser, and you’ll not spend as much time ensuring the HD experience for that section of the audience. They may get the lesser, degraded version without fancy bookmarkable URLs, indeed, they might not even get anything beyond a linear layout and a nod towards typography if that’s what the product owner deems acceptable. What matters is that they can always reach your content.
What “support” means to you and your team can be a many varied thing - but as long as you’ve coded your site using proper web-standards, the risk of your site not working at all is minified.
I like to ensure that the site I work on can be accessed via the lowest featured browser I can find, arguably Lynx - a command line based browser that only understands HTML. It’s not perfect, but it’s a good indicator of what is available on your site to the lowest common denominator.
PE provides you with the confidence that the content is at the very least available to every single one of your users, even if the CSS isn’t rendering or JS playing nicely.
SEO
This is the one that usually has the biggest impact in a discusson regarding PE, because it is the one that has the potential to hit the wallet hardest. If you want search engine traffic coming to your site, you need your site to be readable to search engines.
Much discussion is made in the JS web-app world about how to achieve this. Talk of developing a server side generated equivalent that is hidden behind a hashbang, or that renders HTML in PhantomJS, using 3rd party services that will make your content avilable to (some) search engines via a proprietary specification.
Whichever way, the user is still required to develop 2 versions of the site, one client and one server, which no-one really likes, and is a practice that does raise familiar sounding questions.
For my money, if the HTML first layered on JS and CSS approach is not for you, and you absolutely, positively have to have the latest and greatest web-app running on your site - the hard work achieved by the likes of AirBnB, Meteor and Artsy looks the best bet - a single codebase useable on both the server and front end.
Perhaps this is the Holy Grail we’ve all been looking for?
Every time you say “it depends”, we all take a drink
Ultimately, Progressive Enhancement is an opt-in thing. If you genuinely don’t think you’ll ever need the benefits of PE, don’t utilise it. If the “content” your site provides is transient and shouldn’t be indexable, it’s goals simply do not have a fallback alternative, or you just don’t care, then maybe you can skim through this article with casual indifference.
I feel, however, that the cases when that is justifiable are limited. For the majority of cases, PE is still highly relevant, and necessary.