A while back I read Wesley Aptekar-Cassels' There is no such thing as a static website (via) and had some hard to articulate feelings about it. As I read that article, Aptekar-Cassels argues that there is less difference between static and dynamic websites because on the one hand, a static website is more dynamic and complicated than it looks, and on the other hand, it's easier than ever before to build and operate a dynamic web site.

This is the kind of article that makes me go 'yes, but, um'. The individual points are all well argued and they lead to the conclusion, but I don't feel the conclusion is right. Ever since I read the article I've been trying to figure out how to coherently object to it. I'm not sure I have succeeded yet, but I do have some thoughts (which I'm finally pushing out to the world as this entry).

The first thought is that in practice, things look different on a long time scale. The use of static files for web content has proven extremely durable over the years. Although the specific web servers and hosts may have changed, both the static file content and the general approach of 'put your static files with .type extensions in a directory tree' has lived on basically since the beginning of the web. One pragmatic reason for this is that serving static files is both common and very efficient. Since it's commonly in demand even in dynamic websites, people who only have static files can take advantage of this. Being common and 'simple' has meant that serving only static content creates a stable site that's easy to keep operating. This is historically not the case with dynamic websites.

The second thought is that one reason for this is that static websites create a sharp boundary of responsibilities with simple, strong isolation. On the one side is all of the complexity of the static web server (which, today, involves a bunch of dynamic updates for things like HTTPS certificates). On the other side is those static files, and in the middle is some filesystem or filesystem like thing. What each side needs from the other is very limited. Any environment for dynamic websites necessarily has no such clear, small, and simple boundary between the web server and your code, and on top of that we're unlikely to ever be able to standardize on a single boundary and API for it.

(This is not an accident; the web was, in a sense, designed to serve static files.)

As a result, I believe it will always be easier to operate and to provide a static files web server than a dynamic web server and its associated environment. In turn, this makes static files web servers easier to find. This leads to the durability of static websites themselves; they're easier to operate and easier to re-home if the current operator decides to stop doing so. Or at least it leads to the durability of moderate sized or small sized static websites, ones that can fit on a single server.

This leads to my final thought, which is that the distinction between static and dynamic websites is not blurry but is in fact still quite sharp. The distinction is not about how much work is involved in building and operating the site, or how much changes on it on a regular basis (such as HTTPS certificate renewal). Instead, the distinction is about where the boundaries are and what the sides have to care about. A static website has two clear sides and draws a sharp boundary between them that allows them to be quite independent (even if they're operated by the same people, the two sides can be dealt with independently). A dynamic website has no such sharp boundaries or clear sides, although you can create them artificially by drawing lines somewhere.