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.