[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."