A few more reasons to use Progressive Enhancement

Progressive Enhancement is a methodology where a web application is developed in layers. Each layer works correctly on its own, and additional layers on top enhance the user experience.

The justifications for Progressive Enhancement are usually around graceful degradation – people using older technologies are not left out in the cold, while better technologies are exploited for more cutting edge users.

And that’s fine, but there are more compelling reasons to use PE, in my opinion.

Easier debugging

When developing a modern web app, there is a good chance you’ll want to use Ajax. This allows parts of a page to updates incrementally, so the whole page doesn’t need to redraw.

But what if something breaks? The user clicks and nothing happens. Is it a Javascript error, a CSS thing, or is it a problem on the server?

Using PE, you can avoid these mysteries. First, develop the app to work reliably without Ajax. This means focusing on the HTML experience – button clicks that actually submit forms and links that actually go to a new URL. Debug that to the point that you know the server-side is reliable.

Then, sprinkle Ajax on top. Intercept the clicks and submits, and route them to your Ajax bits. At that point, if something doesn’t work, you can say with reasonable confidence that the problem is client-side.

Here’s a tip: use the same “end point” on the server for both Ajax and traditional requests. (In MVC, this would be the controller action URL.)

The end point should perform the same business logic regardless of whether the request is Ajax or not – so don’t write that logic twice. Instead, you simply vary the end point’s response format depending on the request type (Json instead of HTML, say).

Javascript can fail silently

Proponents of PE will tell you that you need to support users that don’t have Javascript enabled (because they’ve disabled it deliberately, or they are using a downlevel browser on a mobile phone).

That’s valid. But, it’s also an edge case.

The greater danger is that your Javascript will have unforeseen bugs. In most browsers, this simply means that the JS will stop executing without notice. What happens then?

If you’ve authored the non-JS experience correctly and separately, then the experience should fall back to the plain HTML experience. Graceful degradation is an insurance policy for our shortcomings, too.

Division of labor

Each of these layers (JS, HTML, server) is a specialty. If your site gets big, you might have separate people working on each. Make sure the jQuery guy and the server girl can work independently.

Keeping up the discipline

Over time, it’s easy to forget the HTML experience, since your Ajax stuff works so well. Remember, each time you want to add a new feature, stick with the above methodology.

Turn off JS in your browser. Develop the feature. Test it thoroughly. Then, turn JS back on and go to town.

About these ads

One thought on “A few more reasons to use Progressive Enhancement”

  1. Most of what you state is supprisingly appropriate and it makes me ponder why I hadn’t looked at this in this light previously. This particular article truly did turn the light on for me personally as far as this subject matter goes. But at this time there is actually just one point I am not necessarily too cozy with so while I make an effort to reconcile that with the core theme of your point, allow me observe exactly what all the rest of the subscribers have to say.Nicely done.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s