HTML Application or Network Application?

There has been much discussion in the last few years of "web apps". Most of the discussion centers around whether "web apps" that do not degrade gracefully, use progressive enhancement, have bookmarkable pages, use semantic tags, and so forth are "Doing It Wrong(tm)", or if JavaScript is sufficiently prevalent that a JavaScript-dependent site/app is reasonable.

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.

Quite.

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

HTML application

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:

1. Near-universal access
2. Compatibility with a few billion devices of mind-boggling diversity, including many that didn't exist when you built your application
3. Built-in accessibility, which means compliance with legal regulations as well as general human decency
4. Automatic integration with a worldwide network of indexing tools that will make your application findable by 3 billion potential users
5. 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!)
6. An ample supply of trained professionals who are able to build, build on, and further develop your application

Those are all pretty good benefits. Those all come for free with every HTML application built... unless you break it. If your HTML application doesn't have one of those benefits, it means you did something to break it using JavaScript or badly designed CSS.

That should not be taken to mean JavaScript or CSS are bad tools. Far from it; JavaScript is a key part of most HTML applications and offers many benefits in responsiveness, user-functionality, and so forth. However, it is fundamentally an add-on to the basic architecture of networked documents. It's a way to enhance those documents, or allow for partial updates of those documents, etc. It does not, and should not, fundamentally change that underlying architecture: linked structured documents.

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.

Most "web applications" are, or can be, HTML applications. Not all are built that way in practice, but they should be. When they're done well, though, they can be fantastic. My go-to example here is GitHub; fundamentally, GitHub's UI is a massive network of documents (repositories, files, branches, tags, diffs, etc.), and that's how it's built. It's then layered on with a massive amount of Javascript so that document changes are often... not even document changes. Some "page refreshes" are entirely handled via Javascript to make them faster, but that's an add-on (even if a near-universal one) to the underlying model. It's an excellent example of an HTML application done right.

Network Application Tunneled through HTTP

I hereby coin a new acronym: NATH. A NATH is an application that is delivered over HTTP and runs in a web browser, not because HTML is a useful tool (it's often contrary to the application's design) or HTTP is a good network protocol for it (it often isn't), but because HTTP is perhaps the only protocol that is unblocked by nearly every corporate firewall and nearly every computer has a web browser. Many of these applications would be far better served by different technologies than HTML, HTTP, and JavaScript; in years past, they alternately used Flash or Silverlight or Java applets to get away from the HTML/JavaScript part, although that caused various problems. Really, the only advantage "the web" gives such applications is an unblocked port 80.

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.)

In a NATH, the application is almost entirely written in JavaScript. Various tools exist to facilitate that approach, such as the myriad of JavaScript frameworks that have emerged in the last few years (Ember, Angular, React, etc.). These tools either only pretend to be HTML-based, or in some cases don't even bother pretending. They have more in common with traditional desktop application frameworks (.NET, MFC, Cocoa, Qt, gtk, etc.) than with HTML applications. The "web" is an implementation detail, and often an inconvenient one at that.

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.

There are plenty of types of application that make sense as a NATH, even more sense than they would as an HTML application. Email clients, photo editors, mapping software, many system dashboards, spreadsheets, many complex visualization tools, and so on are all good NATH candidates, and there are NATH implementations of all of them. One of the oldest NATHs is arguably phpMyAdmin, a MySQL management tool that incidentally happens to be built with PHP and HTML/JavaScript, but doesn't really have any network-document design to it. That's fine. Trying to shoe-horn an SQL administration tool into a document model would probably make for a mismatched and broken system anyway.

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?

That doesn't mean a NATH should ignore its underlying implementation details. NATHs still need to worry about accessibility, and HTML does provide those facilities if NATHs bother to use them. NATHs still need to worry about variable screen sizes (although they may be able to get away with a narrower range), and CSS handles that pretty well. But for a NATH to break completely without JavaScript is acceptable, as the JavaScript is the whole point of the application.

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.

Naturally, there are some overlaps. In general, I would recommend "if you're not sure, make it an HTML application" as a good guideline, as that is the more forward-compatible approach. There are also cases where an HTML application may have a small portion of it that would benefit from being, in essence, an embedded NATH. A good example here is the Journal of Foreign Affairs, which was built by colleagues of mine at Palantir.net. The vast majority of the site is a reasonably straightforward news magazine site, and thus is a classic web site with a few HTML application bits thrown in for good measure. However, the visual timeline search system was different. The search system allows for querying the entire century-long archive, including drag-and-drop date filters that show, to scale, how many articles there were for a given topic over time. Those filters update the search results in real-time. That functionality is, in essence, an embedded mini-NATH, implemented using Angular. The rest of the site, however, does not use Angular or any other large JavaScript framework, because it would have been counter-productive. It would have broken all of the benefits of HTML and HTML applications that have been honed over the last two decades.

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.