Thinking harder about the surprising return of static HTML.
Static website and blog generators continue to be a very solid and surprising
undercurrent out there. What could be more kitschy on the Web than hand-rolled
HTML? It must be the hipsters; must be the fusty graybeards. Oh, it is—but
we’re also talking about the most ubiquitous file format in the world here.
Popular staticgens sit atop the millions of repositories
on Github: Jekyll (#71 with 35.5k stars—above Bitcoin), Next.js (#98 with
29.3k stars, just above Rust), Hugo (#118 with 28.9k stars). This part of the
software world has its own focused directories and there is constant
innovation—such as this week’s Vapid beta and the recent Cabal.
And I keep seeing comments like this:
I recently completed a pretty fun little website for the U.S. freight rail
industry using Hugo […] It will soon replace an aging version of the site
that was built with Sitecore CMS, .NET, and SQL Server.
Yes, it’s gotten to the point that some out there are creating read-only
web APIs (kind of like websites used by machines to communicate between
each other)—yes, you heard that right!
Clearly there are some obvious practical benefits to static websites, which are listed
time and again:
Web servers can put up static HTML with lightning speed. Thus you can endure
a sudden viral rash of readers, no problem.
While static HTML might require more disk space than an equivalent dynamic
site—although this is arguable, since there is less software to install
along with it—it requires fewer CPU and memory resources. You can put your
site up on Amazon S3 for pennies. Or even Neocities or Github Pages for free.
With no server-side code running, this closes the attack vector for things
like SQL injection attacks.
Of course, everything is a tradeoff—and I’m sure you are conjuring up an
argument that one simply couldn’t write an Uber competitor in static HTML.
But even THAT has become possible! The recent release of the Beaker Browser
has seen the appearance of a Twitter clone (called Fritter), which is
written ENTIRELY IN DUN-DUN STATIC JS AND H.T.M.L!!
Many think the Beaker Browser is all about the ‘decentralized Web’. Yeah, uh, in
part. Sure, there are many that want this ‘d-web’—I imagine there is some
crossover with the groups that want grassroots, localized mesh networks—for
political reasons, speech reasons, maybe Mozilla wants a new buzzword, maybe
out of idealism or (justified!) paranoia. And maybe it’s for real.
No, my friends, Beaker marks a return of the possibility of a read-write Web.
(I believe this idea took a step back in 2004 when Netscape took Composer out of its
browser—which at that time was a ‘suite’ you could use to write HTML as well
as read it.) Pictured above, I am editing the source code of my site right from
the browser—but this is miniscule compared to what Beaker can do.
(Including Beaker’s dead-simple “Make an editable copy”—a button that appears
in the address bar of any ‘dat’ website you visit.)
(And, yes, Twitter has given you read-write 140 chars. Facebook gave a
read-write width of 476 pixels across—along with a vague restriction to height.
And Reddit gave you a read-write social pastebin in
gray-on-white-with-a-little-blue. Beaker looks to me like read-write full stop.)
Now look—I couldn’t care less how you choose to write your mobile amateur
Karaoke platform, what languages or what spicy styles. But for personal
people of the Web—the bloggers, the hobbyists, the newbs still out
there, the NETIZENS BAAAHAHAHAHHAAA!—yeah, no srsly, let’s be srs,
I think there are even more compelling reason for you.
The Web is the Machine
Broken software is a massive problem. Wordpress can go down—an upgrade can
botch it, a plugin can get hacked, a plugin can run slow, it can get
overloaded. Will your Ghost installation still run in ten years? Twenty years?
Dynamic sites seem to need a ‘stack’ of software and stacks do fall over. And
restacking—reinstalling software on a new server can be time-consuming. One
day that software simply won’t work. And, while ‘staticgens’ can break as well,
it’s not quite a ‘stack’.
And, really, it may not matter at that point: the ‘staticgens’ do leave you
with the static HTML.
The more interesting question is: how long will the web platform live on for?
and backward compatibility. I spend a lot of time surfing the Old Web and it’s
most often Flash that is broken—while even some of the oldest, most convuluted
stuff is exactly as it was intended.
Static HTML is truly portable and can be perfectly preserved in the
vault. Often we now think of it simply as a transitory snapshot between screen
states. Stop to think of its value as a rich document format—perhaps you might
begin to think of its broken links as a glaring weakness—but those are only
the absolute ones, the many more relative links continue to function no matter
where it goes!
And, if there were more static HTML sites out there, isn’t it possible that we
would find less of the broken absolutes?
Furthermore, since static HTML is so perfectly amenable to the decentralized
Web—isn’t it possible that those absolute links could become UNBREAKABLE out
A friend recently discovered a Russian tortoise—it was initially taken to the
Wildlife Service out of suspicion that it was an endangered Desert tortoise. But
I think its four toes were the giveaway. (This turtle is surprisingly speedy and
energetic might I add. I often couldn’t see it directly, but I observed the
rustling of the ivy as it crawled a hundred yards over the space of—what
This friend remarked that the tortoise may outlive him. A common lifespan for
the Russian is fifty years—but could go to even 100! (Yes, this is unlikely,
but hyperbole is great fun in casual mode.)
This brought on a quote I recently read from Gabriel Blackwell:
In a story called “Web Mind #3,” computer scientist Rudy Rucker writes, “To
some extent, an author’s collected works comprise an attempt to model his or
her mind.” Those writings are like a “personal encyclopedia,” he says; they
need structure as much as they need preservation. He thus invented the
“lifebox,” a device that “uses hypertext links to hook together everything you
tell it.” No writing required. “The lifebox is almost like a simulation of
you,” Rucker says, in that “your eventual audience can interact with your
stories, interrupting and asking questions.”
— p113, Madeleine E
An aside to regular readers: Hell—this sounds like philosopher.life!
And this has very much been a theme in our
conversations, with this line bubbling up from the recent
I do not consider myself my wiki, but I think it represents me strongly.
Further, I think my wiki and I are highly integrated. I think it’s an evolving
external representation of the internal (think Kantian epistemology)
representations of myself to which I attend. It’s a model of a model, and it’s
guaranteed to be flawed, imho (perhaps I cannot answer the question for you
because I consider it equivalent to resolving the fundamental question of
God, I’ve done a bang-up job here.
I don’t think I can find a better argument for static HTML than: it might
actually be serializing YOU! 😘
I am tempted to end there, except that I didn’t come here to write some
passionate screed that ultimately comes off as HTML dogmatism. I don’t care to
say that static HTML is the ultimate solution, that it’s where things are
heading and that it is the very brick of Xanadu.
I think where I stand is this: I want my personal thoughts and writings to land
in static HTML. And, if I’m using some variant (such as Markdown or TiddlyWiki),
I still need to always keep a copy in said format. And I hope that tools will
improve in working with static HTML.
And I think I also tilt more toward ‘static’ when a new thing comes along. Take
ActivityPub: I am not likely to advocate it until it is useful to static HTML.
If it seems to take personal users away from ‘static’ into some other
infostorage—what for? I like that Webmention.io has brought dynamism to
static—I use the service for receiving comments on static essays like these.
To me, it recalls the robustness principle:
Be conservative in what you do, be liberal in what you accept from others.
In turn, recalling the software talk Functional Core, Imperative
idea that the inner workings of a construct must be sound and
impervious; the exterior can be interchangable armor, disposable and adapted
over time. (To bring Magic: the Gathering fully into this—this is our
Static within; dynamic without. Yin and yang. (But I call Yin!)