In short
Progressive enhancement means building so the core function works with the simplest available technology, then layering improvements on top. The modern case for it is not users who disable JavaScript — it is that JavaScript fails for ordinary reasons: a failed request, a slow network, an unsupported feature, an error in one script breaking the rest. Enhancement decides what happens then.
The principle
Build the core function so it works with the simplest reliable technology — HTML, then CSS — and layer enhancements on top. If an enhancement is unavailable, the base still works.
A form that submits normally, and is improved with client-side validation. A link that navigates, and is upgraded to load in place. Content that is in the HTML, and is enhanced with filtering.
The argument that stopped being persuasive
For years the case was made in terms of users who turn JavaScript off. That group is small, and leading with it made the whole idea sound like accommodating an eccentric minority.
So the argument lost, and reasonably.
The argument that still holds
JavaScript fails for people who did not choose to disable it.
A script request fails — a CDN hiccup, a flaky connection on a train, a corporate proxy. The page loads, the script does not, and if the content required the script the page is blank.
A connection is slow enough that the script arrives seconds late. The page is visible and does nothing when tapped.
A browser does not support something a bundle uses. One syntax error stops the whole file, and everything after it never runs.
An extension, an ad blocker, or a privacy tool interferes.
One third-party script throws an exception and takes an unrelated feature down with it.
None of these people made a choice. They just see something broken, and they have no way to know why.
Progressive enhancement is the decision about what they see instead.
Where it still clearly earns its keep
Content that must be readable. Articles, documentation, product information, legal pages. There is no good reason for text to require JavaScript to appear, and doing so also puts it at risk with crawlers and answer engines.
Forms. A form that posts normally works even when validation script fails. Enhance with inline validation, but let the server validate too — which you need anyway, since client-side validation is not a security control.
Navigation. Real links with real href attributes work when routing fails, can be opened in a new tab, and are understood by assistive technology. A div with a click handler does none of that.
Anything on a poor connection. Mobile data in a rural area, hotel wifi, a busy conference. Enhancement is what determines whether the site degrades or dies.
Where it does not apply
Be honest about the limits.
A collaborative editor, a video call, a mapping tool, a design application — these are not documents with enhancements. They are applications, and JavaScript is the platform. Building a non-JavaScript fallback for a real-time editor is not principled, it is wasted effort.
The useful test: is this a document with interactive parts, or an application? Most marketing sites, publications, e-commerce catalogues and documentation are the former, and are routinely built as the latter.
What it looks like now
Modern tooling makes this easier than the old debate assumed.
Server-render the content. Send HTML that already contains what the page says, then hydrate. Most frameworks support this, and it is often the default.
Use real elements. Buttons that are <button>, links that are <a href>, forms that are <form action>. You get keyboard support, assistive-technology support, and sensible default behaviour without writing any of it.
Let CSS do more. A great deal that once needed JavaScript — accordions, dialogs, sticky positioning, scroll effects, container-responsive layout — now has a platform equivalent that cannot fail to load.
Enhance on capability, not on browser. Check that a feature exists, then use it.
Fail visibly. If an enhancement cannot load, do not leave a control that silently does nothing. Show the base version or say what happened — the same reasoning as error states people can recover from.
The reframe worth keeping
Stop thinking of this as supporting people without JavaScript. Think of it as deciding your failure mode.
Every page has one. Either it degrades to something usable, or it degrades to blank. That is a design decision whether or not anyone made it deliberately.
Test it directly: load your most important page with JavaScript blocked, and with the network throttled hard. What you see is what a real proportion of your visitors already experience occasionally. If it is nothing, that is worth knowing.
If you have a site that is fast for you and unreliable for customers, that gap is usually here — book a call.
Common questions
What is progressive enhancement?
Building so the core function works with the simplest reliable technology — HTML, then CSS — and layering enhancements on top, so that if an enhancement is unavailable the base still works. A form that submits normally and is improved with client-side validation is the canonical example.
Does progressive enhancement still matter if everyone has JavaScript?
Yes, because the modern case is not about people disabling it. Scripts fail for ordinary reasons: a failed request, a slow connection, an unsupported feature causing a syntax error that stops the whole file, an extension interfering, or one third-party script throwing an exception. None of those users chose anything.
Where does progressive enhancement not apply?
In genuine applications — collaborative editors, video calls, mapping and design tools — where JavaScript is the platform rather than an enhancement. Building a non-JavaScript fallback for a real-time editor is wasted effort. The test is whether you are building a document with interactive parts or an application.
How do I apply progressive enhancement with a modern framework?
Server-render so the HTML already contains the content, then hydrate. Use real elements — button, a with href, form with action — so you inherit keyboard and assistive-technology behaviour. Let CSS handle what it now can, and check for feature availability rather than browser identity.
How do I test whether my site degrades gracefully?
Load your most important page with JavaScript blocked, and again with the network throttled heavily. What you see is what a real share of visitors occasionally experience. If the page is blank, that is your failure mode whether or not anyone chose it.
