Ask HN: Has progressive enhancement lost of the war?

12 points by mortallywounded ↗ HN
With the widespread adoption of JavaScript dependent SPAs and frameworks, has progressive enhancement lost the war?

Is there a place for it today?

Edit: For the sake of the argument, let's include tangential ideas like graceful degradation, unobtrusive JavaScript, etc.

10 comments

[ 3.5 ms ] story [ 27.2 ms ] thread
There is no war.

The opposite of a good idea is usually another good idea.

But people often prefer arguing to solving because arguing is easier than actual work.

And winning an argument feels like an accomplishment even though all the work remains.

Good luck.

No "war" ever started. It was just an idea by a few niche people who wanted to disable 1/3 to 2/3 of their browser's technology then demand that web-site operators/builders spend a lot of time and money on implementing for that sub-1% population. They didn't, and these people had no real leverage.

The biggest argument was accessibility, but it turns out people with extra needs don't want a poorly maintained version of the page with a ton of missing features. So instead additional aria tips were added, website operators encouraged (or required by law) to hit A-AAA, to explain parts of the page, combined with assistive technologies getting much better.

The other big argument was in essence "Build first for IE11, then add Firefox/WebKit features on top." Which naturally went away when IE died and evergreen browsers took over.

Yes, it’s dead. UJS still has a place, but it looks like Alpine or HTMX.
Putting state in html is what they called "progressive enhancement", is such a joke for me after years of blowing away traditional backend frameworks for that reason (they're good at API though).

The problem is not about progressive enhancement, the problem is website performance.

What's the alternative? State on the backend, html, and client side code?
Yes this war is lost. The web of 2023 is accessible only from 720p+ screens. If your device is 240*320 or has no HTTPS support then you are not going to browse anything except of HN. And nobody is going to give me an HTTP version (at least read-only) with no handshake overhead requiring at least 2.5G (EDGE) for preventing timeout constraint while using web from a really poor connection.
I’m probably outing myself as an old fart, but I continue to be frustrated that we can’t have web sites that don’t rely so much on JavaScript. Beyond what used to be known as AJAX, I really don’t see the utility for the majority of the javascript that companies want me to run in my browser.

I really hope HTMX gives us a new opportunity to reduce our reliance on arbitrary code running in the browser. Maybe it’s time for “HTML 6” to standardize what HTMX is capable of and move control back to the user.

HTMX is an improvement over full on SPAs, but it's a far cry from the ideal. HTMX still relies on JavaScript and introduces a fair amount of complexity on its own.
That's my point, though. If we were to enable the most important functionality of HTMX at the browser level, we'd remove that reliance on JavaScript.
> I really don’t see the utility for the majority of the javascript that companies want me to run in my browser.

It's not there for you; it's there for them: a large amount of it is advertising and tracking code.