This post was originally going to be a summary of themes from Artifact Conf but, inspired by Jeremy Keith’s presentation, I got preoccupied with progressive enhancement. I also wanted to make this picture of cookies:
Progressive…what?
Pre-Artifact Conf, I was under the impression that progressive enhancement was something very JavaScript engineer-y, and not so relevant to my work. Not the case, it’s much more a mindset than a particular development technique.
In a nutshell, progressive enhancement is building “content out”, separating the structure of a website (HTML) from its presentation and behavior (CSS and JS). Content should be available regardless of the capabilities of the device, and should not rely on styling or scripting to function at a base level.
A good example is the footer anchor navigation pattern in mobile menus. Once the menu works in only HTML, build in the fancy flyout effects. If the browser doesn’t support the flyout effects, it will simply ignore them and fallback to the footer anchor.
Strong Opinions
…very strong.
For
I’ll open the “for” argument with a particularly resonant quote by Jake Archibald from Jeremy’s talk:
When an elevator fails, it’s useless. When an escalator fails, it becomes stairs. We should be building escalators, not elevators.
The most obvious argument for progressive enhancement is supporting users without JavaScript…about 1%. If you have 100k visitors daily that number will add up over time, but is it really worth sacrificing the benefits of JS for 1%? Depending on your visitor demographic, possibly yes, but that’s by no means the only argument for progressive enhancement.
Progressive enhancement makes a lot of sense when we think about the actual workings of a browser. HTML content is loaded first, then CSS, and finally JavaScript. Any content dependent on JS on won’t appear until the very end of the page load process so if your Internet connection sucks, that may cost a few seconds and a lot of money.
Against
Enter JavaScript frameworks and web apps. Tom Dale, the creator of Ember.js, wrote a harsh response to Dan Mall’s Tumblr Sigh, JavaScript, declaring progressive enhancement to be backwards and dead:
We live in a time where you can assume JavaScript is part of the web platform. Worrying about browsers without JavaScript is like worrying about whether you’re backwards compatible with HTML 3.2 or CSS2.
By compensating for older technologies and edge cases, are we inhibiting innovation on the web?
My Take
Overall, I think it depends on the project. For the type of work I do, progressive enhancement is very valuable – the best practices it encourages are excellent for a small business website made of mostly static content and a few UX-y flourishes. However, for highly interactive web applications like Instacart or Feedly whose user base is primarily affluent 20-30 somethings, sure, make something flashy that pushes the web to it’s limits.
Sidebar: I disabled JavaScript while writing this post to test some things, forgot I had, and was momentarily confused when WordPress stopped functioning…
Sources:
- Progressive Enhancement: It’s About the Content – Happy Cog
- Understanding Progressive Enhancement – A List Apart
- Progressive Enhancement is Dead – Tom Dale
- Jeremy Keith on building with progressive enhancement – Creative Bloq
- Sigh, JavaScript – Dan Mall
- How one second could cost Amazon $1.6 billion in sales – Fast Co.