When to use Graceful Degradation and when to use Progressive Enhancement?

Question

When creating a website or web application, there is always the problem of what to do when not all browsers implement all desirable features. From what I’ve read, there are two main ways to deal with this:

• Graceful Degradation ("Smooth Degradation") - Develops thinking of the most complete environment possible, but ensuring that if functionality X or Y is absent the site still works as well as possible without it.
• Progressive Enhancement ("Progressive Enrichment") - Develops thinking of the most basic environment possible, and adds extra features if the presence of X or Y functionality is detected.

What are the advantages and disadvantages of each of them? Are there situations where one is more suitable than the other, or is it just a matter of preference? I am mainly interested in the aspect of maintainability: as new features are being introduced to browsers, and old versions of them fall into disuse, what are the implications of this on a site/application developed according to these strategies?

Answer 1

Technically there is no difference

With both approaches it is possible to implement compatibility with any browser, in any version. The difference between them is like an approach top-down or bottom-up, but in the end you can achieve the same results.

Strategy can influence team mentality

For example, the Graceful Degradation ("Soft Degradation") will somehow prioritize newer browsers, since the reasoning is: implement the newest, and if not, use plan B to maintain compatibility.

Already the Progressive Enhancement ("Progressive Enrichment") will produce the opposite effect, putting compatibility at the forefront: we will make it as simple and, when possible, we will improve a little.

Limitations that make a difference

Unfortunately, today it is still necessary that we test the various browsers and different devices to really ensure the proper functioning of a system. And I think it’s inevitable that the team will end up focusing on the most immediate functions to their reality.

Then we are faced with two restrictions:

• The developer will give preference to a specific coding environment, which inevitably increases the chance of errors in the "secondary" environments he has had less contact with.
• The limitation of time and resources makes it not possible to carry out adequate test batteries in all possible scenarios.

Completion

With all this, my conclusion is that the feature detection technique of a browser (or lack thereof) is no more important than the correct definition of a development and testing strategy.

Since in general you cannot have everything, then you need a clear definition of the target audience and the most likely scenarios of using the system.

If the trend is for users to use more modern browsers, then it’s worth getting started by taking on the newest features. When the browser does not have any functionality, Smooth Degradation applies. If it gives any problem, at least it will reach the minority of users.

Already in another scenario, imagining maybe a government agency or a large company, where the updating of browsers is very slow, it is better to use less of the new features and, in certain scenarios, can then enrich the system. Similarly, few users will be impacted if there is a problem because of this.

Answer 2

@utluiz is right when he says that technically there is no difference. The antagonism between the two terms (they are not technical, they are more for philosophies) today is not as strong as it once was, and we need to remember where they come from. One is actually an evolution of the other, and what is currently used is the result of that evolution, and in a way a combination of the two.

Graceful Degradation

When did the expression Graceful Degradation, there was no standardized support for the most basic resources, and chaos prevailed. The browser with the largest market share had numerous CSS bugs, and did not support the W3C Javascript Apis. The browser update cycle was much slower than today. Many websites and applications broke into one or another browser - not to mention mobile devices, which were much more rudimentary and much less present.

When there was support for two or more browsers, this was done with browser detection techniques and browser-specific versions, which soon proved unsustainable. Then came the emphasis on a more elegant solution, hence Graceful. In practice, came the exchange of browser sniffing for Feature Detection. Instead of coding for one or another browser, it is verified whether the user’s browser supports a certain feature, and it is decided how to react to its presence or absence.

Progressive Enhancement

This model was a step forward towards a web cross-browser. Arose polyfills and shims, "buffers" for unsupported features, better leveling out what was possible to do. At the same time, movement was gaining ground by semantic marking, positioning techniques in search engines, mobile devices. This soon led the focus of development to move from resources to content. And only then did the current of Progressive Enhancement, that represented exactly this change of emphasis: from degradation (of resources) to improvement (of content). The distinction may seem subtle, but it’s important. The spirit before was to deliver "ugly" content if there was no other way. It is now to deliver "naked" content and add layers for those who can take advantage of them.

The technique that makes this possible has not changed much, it remains Feature Detection, added to a greater care with marking. This became simpler to achieve as browsers evolved.

In practice

When starting the development of a website or web application, you will always take into account:

• Your target audience
• The content that will be displayed
• The features that this content requires

Notice what I said demands in the last item. For example, if you create the site from a Javascript library for canvas manipulation, it is obvious that the library’s demo pages will depend on canvas support. Using Feature-Detection, you can show a screenshot and/or a message saying that canvas is a requirement, but it makes no sense to implement a functional version without canvas (for example, in Flash) if the purpose of your library is not to replace the canvas when it is not available. The library’s documentation pages, without working examples, should work on more browsers and devices, as they impose fewer limitations.

That is: its content is in charge (content is king). That’s in the spirit of Progressive Enhancement, but practical application (display alternative content or alternative appearance when there is no support for X) can also be seen as Graceful Degradation.