[parris]

This is non-sense. Every few minutes you hear someone complain about the lack of progressive enhancement. The case for progressive enhancement is only valid when you have "content" that is easily parseable by human eyes.

In a world where you have too much data and users want to see slices of data, progressive enhancement fails to deliver a fast, pleasant, engaging user experience. In the case, where you have complex tools that help a user meet some end goal more quickly progressive enhancement falls short of providing the easy to use tools. The only case where this works in any way shape or form is when a site is submittable via simple forms and all data can be retrieved by visiting urls. Any, slightly more complicated use case fails to be delivered at any reasonable pace with any sort of reasonable performance. You know the kind of performance that wouldn't make your server side fall over.

This whole progressive enhancement thing is mired in decade old dogma. While progressive enhancement can work sometimes, it is NOT the only tool. We shouldn't wholesale prescribe solutions without knowing someone's problem.

[JoshTriplett]

Progressive enhancement does make sense in some cases, such as using a feature that not all browsers support yet but that the site can function without.

And progressive enhancement makes perfect sense for things like CSS; if your site content makes no sense with CSS turned off, it probably makes no sense with a screen reader. So, for instance, remember to put content in a sensible order in the HTML rather than arbitrarily rearranging it with CSS.

However, I no longer think progressive enhancement makes sense for things like JavaScript, as long as you use features just about every browser supports. Otherwise, you'd have to effectively write your site twice: once with JavaScript, and again as entirely forms/links and server-generated content.

The critical reason why I no longer think this makes sense: because it's completely sensible to follow an API-first approach to site design, where the first thing you write is an API usable both by third parties and by your own first-party site. Then you can write your site on top of your own API. I don't think we need to target human-readable first; on the contrary, I think we get a better, more extensible, more programmable, more open web if we build APIs first and foremost.

Now, all that said, there are other ways this article is completely right about not breaking the web. In particular, having an app is no excuse not to have a website, or one not usable on mobile. And if you're going to display a "you might want the app" banner, have a "go away and stop asking me" that does not break navigation to the specific page the user was trying to visit in the first place.

[compbio]

Progressive enhancement for JavaScript is not only a accessibility and usability issue, it has become a security issue. Tor enabled JavaScript by default, because the web would break without JavaScript support, and that hampered adoption rates of Tor.

We already had a programmable web. If anything we are moving away from machine-readable code.

If progressive enhancement does not fit your development style, and takes too much time to build, well... fine. I see this not as a fault of progressive enhancement, but in your approach. To me it is akin to saying that writing unit tests takes you too much time, and hence, testing makes no sense.

[lnanek2]

I think the article was pretty clear about API first being bad, and even linked to Twitter's write up of having to tear out that failure: https://blog.twitter.com/2012/improving-performance-on-twitt...

[JoshTriplett]

I don't actually think an entirely client-side-rendered application makes sense; on the contrary, I do think it makes sense to do most HTML generation on the server, and where appropriate, hand out snippets via the API, rather than handing out JSON or similar and making JavaScript produce HTML. But that's different than rendering entire HTML pages entirely on the server. And for primarily dynamic content, I see nothing wrong (for many sites, at least) with assembling server-provided HTML snippets from JavaScript into a server-provided HTML base page, without any fallback to an entirely server-provided page.

[parris]

Of course/agreed! It took me a while to get there, but basically the conclusion I was trying to make is "it's not the only tool please stop prescribing for every scenario blindly."

[idonthaveaname]

> This whole progressive enhancement thing is mired in decade old dogma. While progressive enhancement can work sometimes, it is NOT the only tool. We shouldn't wholesale prescribe solutions without knowing someone's problem.

The "first load" problem is a recent addition to the canon of reasons why progressive enhancement is a solid approach. I think that trashes your argument that this is "decade old dogma".

And to further counter your point, the notion that "decade old dogma" is "bad" is refuted by success of POSIX/UNIX. And wheels. Some "old" ideas are still state of the art.