What am I missing about Progressive Enhancement?

I remember when I first read about progressive enhancement. It was back when you couldn’t depend on everyone having javascript. So the case for building a functional site without javascript first, and then enhancing the experience for those with javascript made sense.

But now javascript is ubiquitous. Even screenreaders have it. That argument holds much less weight. Is there still a good case for progressive enhancement?

I suspect there is, because “we don’t need progressive enhancement because everyone has javascript” feels a lot like “we don’t need TDD because there are better ways to catch bugs”, an argument that I disagree with the very foundation of.

I remember when I first read about TDD. I was exposed to it as a way to prevent bugs. The things I were building were small, and I hadn’t experienced many maintenance headaches yet. So the case for writing some tests to make sure your “code was working” made sense.

But then it became cumbersome, and I still had bugs. The time it took to write and maintain the tests didn’t seem worth the effort. Is there still a good case for TDD?

For me, yes, there is. I soon learned to use TDD as a design tool first, and a safety net second. This made the effort worth it again. Is there a similar benefit to Progressive Enhancement? Something that provides value besides “it works for people without javascript” that makes it still worth the effort?

I think there’s something there that I’m missing. So I’m asking you. If you have thoughts, please comment.

2 thoughts on “What am I missing about Progressive Enhancement?

  1. For me, progressive enhancement is not about catering to those who do not have javascript. It is about catering to my own fuck ups. When that bug ships and the entire bundle eats it, I pray the login is still functional.

    Javascript is absolutely ubiquitous, and on all my devices it is blazing fast, but it is a complex machine that takes a noticeable moment before it hits warp speed. That moment is unreasonably agonizing.

    I’d very much like to step back in time a bit. Comb through my apps, isolate the premium essentials and figure out the best way to render those bits server-side.

    Note: I’m regurgitating sentiments that resonated with me from Jake Archibald’s post:

    And as I understand it he got some flack for it and wrote the followup:

  2. Progressive enhancement is not limited to JavaScript, in fact it isn’t concerned with any specific technology. Rather, it’s a philosophy that asks us to create a single universally usable experience and then use technologies to smartly improve that experience as we’re able. As blueback mentions, it creates incredibly resilient interfaces that fall back to a lower fidelity but equally usable state.

    I use several analogies for progressive enhancement but one I thought of while writing the 2nd edition of Adaptive Web Design (which is all about progressive enhancement) has to do with music. Imagine the baseline experience is like listening to a song in mono. It’s enjoyable, but not nearly as rich as stereo, or 3.1 surround sound, or 5.1 or 7.1, or hearing it performed live in a perfectly constructed music hall. We can engineer songs that are absolutely astounding in 7.1 channel surround sound, but just because that’s our focus doesn’t mean that the person listening on a crappy mono Bluetooth speaker can’t listen to it too. Sure it’s not the ideal, but that’s ok… we can and should meet our users where they are not where we ideally want them to be.

    Content is the core. Markup is an enhancement adding semantic value and improving the interface. Design adds visual hierarchy, reinforces brand, and helps guide the eye. Interactivity increases the number and quality of affordances and further reduces the friction of accomplishing tasks. They all work together to improve the core experience but none are required to have that experience. That’s the idea of progressive enhancement.

Leave a Reply (markdown is supported)