One problem with the debate around Progressive Enhancement is that it bundles together a bunch of concerns and tactics under a single label.
The way the debate has played out has turned a landscape of problems into a binary decision: Progressive Enhancement or Not?
Which then gets caricatured further into: JS or Not?
Neither of which accurately represents the concerns of either camp. Once you get into reading about the respective methodologies—their self-described best practices—it turns out that they’re both a diverse set of tactics for solving web development problems, each covering a wide range of scenarios and problems.
Instead of bundling each broad approach under reductive labels, it pays to think of them as a spectrum of tactics for solving web development problems. (Which, by the way, is how most Progressive Enhancement promoters actually present the issue. Unfortunately reductive labels are a really powerful tool for diverting a debate to where it doesn’t belong.)
If you’re a die-hard, pro-JS web developer, try thinking of Progressive Enhancement as a set of robust and historically well-tested methods for hydrating server-rendered DOM conditionally and in stages depending on client capability.
Sometimes those conditions and stages can be implemented declaratively without having to use JS. Which is cool, right?
What the Progressive Enhancement camp is saying is that for a lot of projects the methodology they are promoting has a huge upside in terms of user experience, conversion rates, and overall ROI. The benefit of progressive enhancement on initial load times, for instance, can be tested pretty objectively and that’s a metric that feeds directly into ROI for a lot of business types.
Not to mention that if you work in the public sector, Progressive Enhancement is usually the most cost-effective tactic available for fulfilling your legal requirements in terms of accessibility and reach.
Don’t make up your mind about Progressive Enhancement by reading reductive blog posts or presentations that gloss over or outright ignore the details and nuances of actual web work. Read up on the individual tactics used. Judge them in terms of how effective they might be at solving the problems you are tackling. Every tactic strikes a different balance. Unless you plan on only solving one kind of problem, again and again, throughout your career, you owe it to yourself to study the tactics that lie outside your comfort zone.