How I Host This Website

← Back to root

Or: A Full Explanation of Computers and Static Web Hosting, for the Uninitiated, for the Purpose of Explaining a Twenty-line Program To My Family

I manage this website myself, with the inanimate help of some open-source software and a rented server.

Foundations

Imagine opening your web browser (probably Chrome) and typing or clicking a link. Your web browser takes that link and wraps it in some extra data; think of the information you have to put on envelopes before the mail service will take them. Given the example link

https://example.org/awesomearticle.html

the request says something like:

I’m requesting a resource named “awesomearticle.html” from the computer associated with the name “example.org”.

The computer that receives this request is responsible for “serving” the resource back to your computer, so it’s called the “server” in this context. The server can use any method it likes to produce “awesomearticle.html”. It could:

Definition: Static Website

“Static” describes websites that only use the first option in the list above. tykozic.net is a static website. To deliver my thoughts to you, I copy files from my laptop to the server I rent in a datacenter somewhere. My server sends them to you unaltered. How intimate.

HTML

Web pages, in general, are more than just text. There are fancy boxes, grids, scrolling image sequences, tables, and more.

These elements are represented in a language called HTML, the Hypertext Markup Language (Hyper-text, hyper-link. Coincidence? No.). Basic text, typical of my pages, looks like this:

<body>
<p>
  p is for paragraph.
  I can embed a link like this:
  <a href="/awesomearticle.html">
    this will end up underlined and blue-ish.
  </a>
</p>
</body>

It’s for computers, not humans. It’s unambiguous so that a computer and human can fully agree on the page’s structure.

For comparison, the text you’d see is only this long:

p is for paragraph.
I can embed a link like this:
this will end up underlined and blue-ish.

There are many letters in the HTML that humans don’t care about while reading. The ratio gets worse as a page incorporates more complex elements than text. A small table looks like this:

<body>
<table>
  <tr><th>Candy</th><th>Ty enjoyment factor</th><th>Tongue injury factor</th></tr>
  <tr><td>Chewy Spree</td><td>8</td><td>4</td></tr>
  <tr><td>Sour Patch Kids</td><td>10</td><td>8</td></tr>
  <tr><td>Black Licorice</td><td>5</td><td>0</td></tr>
</table>
</body>

I’ve always assumed th is for “table heading” and td is for “table data”. That HTML contains many more characters used for formatting than for human communication. Plus, it’s barely legible.

Not HTML

I don’t write posts directly in HTML (except for one period of odd motivation). There are plenty of good alternatives. Hosting platforms like Squarespace and Weebly, if those are still around, will let you drag and drop elements and type in familiar rich text boxes. They handle converting that to HTML.

I choose to write my posts in plain text markup languages and use small programs to convert them to HTML on my own computer. I write in a simple text editor. Imagine the simplicity of Windows’ Notepad with nicer visuals and the strength of fancy code editors.

Here’s our HTML from before:

<body>
<p>
  p is for paragraph.
  I can embed a link like this:
  <a href="/awesomearticle.html">
    this will end up underlined and blue-ish.
  </a>
</p>
</body>

Here’s how it looks in a format called Markdown:

p is for paragraph.
I can embed a link like this:
[this will end up underlined and blue-ish](/awesomearticle.html).

Notice a few things:

Here’s a format called gemtext:

p is for paragraph. I can embed a link like this:

=> /awesomearticle.html this will end up underlined and blue-ish.

Gemtext is incredibly simple. Every link needs its own line!

Problems

Ideas pour out of my brain, and suddenly I have a huge folder of Markdown files. Converting one file is easy; I can feed it into a program and save the output to an HTML file with a similar filename. It’s easy enough to automatically repeat that action for each file. But what if I have subfolders and sub-subfolders of files? Is it still easily repeatable?

Programs called “static site generators” solve this problem. They’re able to read any hierarchy of files, usually Markdown files, and produce a hierarchy of HTML files with the same structure.

What if I want to tweak an HTML file after it’s generated? The static site generators I’ve seen don’t support this easily. I have to remember to make the same change after every run, since the program will overwrite the HTML every time. Or I have to omit the file from generation and incorporate later edits manually.

And what if I want to try out a new format? Imagine this relatable scenario: A friend tells me about an esoteric format that exclusively uses the names of famous boy bands to denote different page elements. Which name corresponds to which element type is based on the current popularity rankings of the bands based on monthly Spotify listens. He says using it, and therefore keeping up with the boys, has changed the way he sees the world. I have to try it! But a strong majority of static site generators won’t recognize this format. I don’t know why not. Tell me why!

(Disclaimer: I don’t actually know a lot about boy bands. I will only disappoint you.)

Solution

Static site generators prioritize ease over control. I can write five hundred posts in a reasonable format, then press a button and get the output. That’s great! But given the problems above, some of which are particular to me, I wanted the trade some ease for control. Five hundred posts? Who am I, Niklas Luhmann? I can afford to give each post some housekeeping time.

A tiny program I wrote, called “dirmake” for now, reads a directory (that’s Linux for “folder”). It creates an output directory of matching structure. That’s in line with existing tools.

Instead of insisting on a particular conversion process, like Markdown to HTML, for every post, dirmake lets me specify the conversion process individually for each post. That’s the only difference, but it’s powerful. I can write pages in Markdown, gemtext, plain HTML, or anything else you can nsync of.

Go here for source code and slightly more technical details.

So I write input files, write conversion programs for each post (these rarely exceed a few lines that connect other programs together), run dirmake, then copy the whole output directory to the server.

That’s how I get to you, and this is how I leave you.

Ty