The theory versus the practice of “static websites”

July 14, 2023

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.

Read More