Nolan Lawson has written a great piece about progressive enhancement that brings up some fascinating points. An over-simplified summary would be: progressive enhancement doesn't mean it works without JavaScript, it means it works without network. As a web developer of the oldest possible school, it's interesting to me that the most vociferous objections to his position seemed to be coming from similarly old-school devs (that was a totally subjective impression and might be wrong).

Offline-first is great for web apps

Right off the bat, I think it's important to acknowledge that I think a single-page application that works offline in 2016 is definitely doing more useful for its users than that same application rendering entirely without JavaScript. That seems to be where Nolan is coming from, and as far as it goes I agree. But I think early on he dismissed another interpretation that is equally important.

He mentions, briefly:

Paul Lewis is a big fan of progressive rendering for performance reasons

and then moves on with his argument about apps that require JavaScript, paying particular attention to the "next billion" users who will have decent, JavaScript-capable phones but crappy network connections.

But it seems to me this conflates two very different use-cases that we should consider separately:

1. A single page web app (an "app" from here on)
2. A website that consists of multiple pages (a "site" from here on)

Not everything on the web is an app

The generational disconnect I mentioned earlier seems to be coming from the fact that web developers are in two groups, with different "default" ways of thinking about web development. The first group, who turned up in the past 5 or maybe even 10 years, think of it as application development with the web as a medium. The second group, which includes myself, who started 20 years ago think of it as building a set of discrete pages. Obviously, both groups can and do build both types.

Progressive rendering isn't very useful for apps

If you are developing an app, the user ideally loads the app exactly once -- whether it's over a slow connection or not. Whether or not it's bootstrapped, they take the hit of activating the JavaScript one time, and then the app works. Given that the app is complicated and probably takes a while to load, optimizing for app caching and an offline experience is definitely worth the trouble. A single page app probably doesn't have any good use case for JavaScript turned off, because an application without JavaScript cannot really be interactive, and another name for a non-interactive application is "broken". Progressive rendering doesn't really make any sense. This was Nolan's point and I'm on board.

But if you are developing a web site consisting of many discrete pages, the act of loading goes from a single event to the most common event. Content sites of all kinds -- news, entertainment, whatever -- and lots of e-commerce applications are, and for good reasons probably will always be, page-based rather than applications. These types of sites can have a great JavaScript-less experience: it's easy to read an article with JavaScript turned off, and you can click a "buy it now" button without JavaScript as long as it's a real button.

Progressive rendering is essential for sites

In a web app, a user has exactly one chance to experience a catastrophic loading error -- getting their connection cut off mid-load, say, or a JavaScript error completely torching all other scripts on the page. Somebody who experiences this will reload and get on with things, probably. You want to minimize the chances of it happening, but it's not really very common in the first place, so you can probably dismiss it.

On a multi-page web site, on the contrary, the number of chances users have to experience a catastrophic loading error rises by orders of magnitude. In fact, it's almost guaranteed in a world of mobile connections that your users will experience half-loaded pages, and on ad-supported content sites, crappy ads will break your scripts another big chunk of the time. In this situation, optimizing for progressive rendering is an obvious imperative: the JavaScript-less case is both useful, and guaranteed to happen.

Long live web development, in every flavor

As I argue every time I give my Stuff Everybody Knows talk, web development is not a competition between single page web apps and multi-page web sites. Neither is going to "win". There will always be both kinds of web experiences, and what counts as "graceful degradation" is very different depending which one you're building.

Nobody's arguing that graceful degradation is a bad policy, merely what it looks like, and I think these widely diverged use-cases is the source of the disagreement. In fact, as I mentioned on Twitter early this month, web app development and web site development are so different now that they probably shouldn't be called the same thing anymore. Both types of developers are web developers, but you should probably specify which flavor you're talking about. Web app development and web site development (pick your own terminology if you don't like mine, just make it unambiguous) are so different now that rules from one flavor almost never apply to the other.