What I fear is all too often missing from these discussions is that there isn't one type of "web app". Just because two "things" use HTTP doesn't mean they're conceptually even remotely the same thing.
What is a web app?
As usual, let's start with Wikipedia:
In computing, a web application or web app is a client-server software application [in] which the client (or user interface) runs in a web browser.
It continues, however:
The general distinction between an interactive web site of any kind and a "web application" is unclear.
The Wikipedia article goes into more detail about how web applications differ from native apps, and is a worthwhile short read. However, it doesn't try to classify web apps themselves. That is something I feel the industry as a whole is missing.
I would, broadly, define two different classes of "Web app".
An HTML application is one that, broadly speaking, fits the general architecture of HTTP and HTML. HTML is, at its core, a document structure markup language. The key word there is "document". HTTP (if one subscribes to the REST worldview, which as HTTP 1.1 was designed in concert with the REST model you really ought to at this point) is a loose network of uniary-linked resources. HTML documents are the primary form of resource, although there are of course others (CSS files, images, etc.) Thus, the native architecture of the "web" is: A loose network of uniary-linked structured documents.
While I'm sure at this point someone is getting ready to say "well it was, but today...", hold off for a bit. It's entirely true that a tool can be used for more than it was originally intended for, and that's fine, but that doesn't mean the fundamental architecture can be ignored entirely. If you're dealing with HTML/HTTP, you are dealing with tools designed for networked structured documents. That means it lends itself really really well to applications that generally fit that model.
Is your application, overall, compatible with networked structured documents? Can it be, if you look at it from the right angle? Great. That means it can be reasonably implemented as an HTML application, with all of the benefits that come with that. Those include, among others:
- Near-universal access
- Compatibility with a few billion devices of mind-boggling diversity, including many that didn't exist when you built your application
- Built-in accessibility, which means compliance with legal regulations as well as general human decency
- Automatic integration with a worldwide network of indexing tools that will make your application findable by 3 billion potential users
- The ability of those 3 billion users to actively support you via sharing of links, that is, plugging into that networked document cloud (free advertising!)
- An ample supply of trained professionals who are able to build, build on, and further develop your application
That's where the "progressive enhancement" phrase comes in: That approach takes a series of networked documents and enhances them — with visual effects, with opportunistic feedback, with pre-fetching of data, and other forms of mutating the document client-side — in ways that are (or can be) highly beneficial. Criticism of progressive enhancement for crippling applications is entirely unfounded. It's simply a question of how those benefits are layered in, in ways that are with-the-grain of the underlying linked structured document architecture.
Network Application Tunneled through HTTP
And that's OK.
No, really, it's OK. These applications are in many ways a throwback to the "thin client" models of mainframes from the 1970s and 1980s, just as Sun and Oracle predicted almost 20 years ago. (They got the hardware and commercial model wrong, but the basic concept came to pass.) But a common and universal delivery channel is needed for that to work, and HTML/HTTP is, well, the only option available. (Mozilla's XUL was a possible alternative, but Mozilla actively fought to keep it from becoming an HTML alternative for application development.)
There are even "web standards" that actively facilitate NATHs, such as websockets. Websockets piggy-back on HTTP, but once a connection is established have basically no similarity to the REST model through which they are tunneled. The various plans around "web assembly" are also targeted squarely, and exclusively, at NATH implementations.
As they only incidentally use "the web", NATHs often ignore many web architectural benefits that wouldn't be relevant to them anyway. What does a URL mean in an online photo editor? I suppose it could refer to a particular photo, but trying to squeeze all application state into a URL so that it could be bookmarked makes little sense. Who cares if a given layer is visible or not from a bookmark?
Know the difference
Here's where the confusion and contention comes in. A NATH has a lot of benefits. NATHs are where the "cool" is these days, and where the cool-looking tools are coming from. However, that doesn't mean a NATH is the right approach for your application.
Do not use NATH tools to build an HTML application
It's that simple. Know the difference in the tools you're building. Odds are, most systems you're building on the web can be represented as an HTML application, and thus get all of the benefits of an HTML application. Using NATH tools just because they're cool, or you want to not have to talk to your server-side developer to make changes (a sure sign of a bad developer is one that doesn't want to collaborate), is the good intention that paves the way to Hell. However, if you really would be better off with a NATH, go all-in and don't pretend you're building an HTML application. You're not. You're just taking advantage of its firewall rules. Own that decision.
The next time you're debating about web standards, the "proper" tools to use, and so on, bear in mind that "web app" is not a singular thing. Most of the web is web sites and HTML applications that can, and should, leverage the networked structured document architecture as much as possible as there are enormous benefits to doing so. Ignoring them just to chase cool and shiny is doing yourself and your users a gross disservice. However, that doesn't mean NATHs don't or shouldn't exist. They do, they can be extremely powerful and effective, and are the right tool for some jobs.
But don't try to confuse HTML applications, and their tool-chain, with NATHs and their tool-chain. That's where the messy, 2 MB-of-JS-to-read-an-article nonsense comes from, and you really, really don't want to find yourself in that swamp.