What happened to progressive enhancement?
I've only learned about (and started championing) progressive enhancement in the past couple of years, but I get the impression that it was something that used to be far more common than it is today.
It seems that the principles that progressive enhancement were built on top of—making sure that all users can use the core functionality of your site, regardless of their connection and browser— are as valid concerns today as they were 10 years ago. I don't think that the idea of progressive enhancement is out-of-date. But I do have some other theories about why we're seeing less of it, and I'll explore them now.
The need to make features look exactly the same in every browser
If you think that supporting Safari is a pain, let me take you back to the beginning of my career, when we had to worry about supporting IE7.
When a product manager or a stakeholder reports to the development team that something is not working correctly on IE7, I was never on a team with a progressive enhancement culture. The response to the push back was always to try and make something look exactly the same and function exactly the same as it did in more modern browsers, regardless of the performance cost.
This is diametrically opposed to the philosophy that fuels progressive enhancement.
Let's take the example of the rounded corners. When IE9 came out, this was as easy as using the border-radius CSS property. In Internet Explorer 8 and below, if you wanted rounded corners, you had to resort to hacks like using background images.
With a progressive enhancement culture, the development team could embrace the fact that making rounded corners before IE9 came out was a pain, and fall back to regular corners in IE8 and below. The site may look different for those users, but it doesn't affect the core functionality of the site
The proliferation of SPAs (single page applications)
React came out in 2013, and ever since then, the use of single page applications has risen exponentially. In many cases, applications are built with no JavaScript fallback; if JavaScript fails to load, users could only see a loading spinner or a blank white page.
I think that this has affected progressive enhancement in two main areas.
1. "If the user doesn't have JavaScript, that's their problem"
By serving only a blank white page when the application doesn't load, this is the opinion that many single page applications subconsciously give. Most modern browsers will be able to serve your JavaScript without any problems, but there are many other cases that could yield problems (see Everyone has JavaScript, right?).
2. The barrier of entry to a web development career has been lowered
I think that this is generally a good thing, but it has also led to the "bootcamp-ification" of web development, often using a SPA like React as a starting point.
The lowered barrier of entry could make it easier to brush over progressive enhancement, and get straight to the finish line of running a to-do list application in the browser.
Modern computers are powerful (and modern Internet connections are extremely fast)
If the people who build websites are working on 2023 machines with 500+ mbps Internet connections, it's hard to envision what the browsing experience is like for a less fortunate user. In those environments, the difference between a performant website and a non-performant one could be only fractions of seconds. Without seeing where things can go wrong, it's hard to account for them when building sites.
It's more work
The elephant in the room about progressive enhancement is that it's a lot more work to build a site with it in mind than it is to ignore it.
I'm of the opinion that it's extremely worthwhile work, but it's definitely requires more time investment to build something with progressive enhancement than it does to build something without it.
And it's a huge mindset shift. If you're used to building something with the assumption that the user not only has JavaScript, but also has the latest JavaScript features (and also the latest CSS features), it's hard to think about fallbacks to build when those things aren't the case.