A long time ago, all the way back to 2006 I decided that I wanted to have my own domain, partly to have a stable address for emails (I had previously used several now-dead email services with their domain), and partly to have my own website for "stuff". So I registered

Then for 10 years I had a wiki instance running on PHP with a custom theme, hosted on the web host where I also had the domain registered. However, over time it required maintenance and PHP is not really something I'm interested in. The PHP version became outdated, the wiki probably had security issues and so on. I took it down.

I had in the back of my head that I should do something to put it up again...

The recently, in end of 2023 I started to think it could be nice to have a site again, and I took action. I got inspired by this long discussion on HN: Ask HN: What has your personal website/blog done for you? At the same time I recently changed jobs, and I could see similarities between them which would make for good blog posts (at least I hope so!).


I could quickly identify a couple of (not so easy to combine) requirements:

Site Tech

Something that has become popular the last years is static sites generated with a static site generator such as Jekyll or Hugo. This approach would definitely fulfill the first requirement of a static site.

However, using a site generator has its problems. I write the documentation for Pymunk with reStructuredText and Sphinx. But it also means that I sometimes need to update sphinx, and things can break etc. It also means I have to have Python and the modules installed somewhere to generate the output. For Pymunk it works well, I need to maintain Pymunk and update its dependencies, update Python versions etc. anyway. It needs to have a build pipeline regardless of its documentation. But this site shouldn't need to have all that!

Ok, then what to do?

Well, there were two options I could think of. Either write HTML directly, or write content in something that can be rendered into HTML client site, in the browser.

I found an interesting JS library called Marked which parses markdown files into HTML, and can run in the browser on page load. This could be a nice compromise! On the positive side, I can write content as Markdown, which (in my opinion) is a bit nicer that raw HTML for this type of content. The downside is of course that the clients will need to get the JS, and then render the site on each page load.

This sounded like an interesting technical challenge as well, could it work?

I made the site with Marked, and wrote two blog posts in Markdown with it. It worked decently, until I needed to do some adjustments. I needed a sitemap, and for sharing content I needed a meta header. Then the final straw was when I discussed with my co-worker, and he stated what I knew but didn't want to know. Why not just write the site in good old HTML? Much less complexity. With this, I decided to throw away Marked, and go all in HTML (with some sprinkle of JS and CSS of course).

Good news is I learned a thing or two by looking at how to implement Marked. First off that a minimal HTML site is actually very small. I also saw how some things can be injected with JS, such as common content like header or footer, and that the site can still feel very snappy.

With the change to HTML, the site now consists of the following features

  1. The actual content
  2. Some styling to make it decent looking
  3. Some common things like header and footer
  4. Number of visitor statistics

Inspired by the Marked "helper" library Texme I have a JS file that loads first, with the following functionality:

  1. Add CSS tag with Sakura and my own modifications
  2. Add header and footer HTML, and a main tag.
  3. Add meta tags
  4. Add title tag, or if present add h1 tag
  5. Add GoatCounter "pixel" for counting visits

Each HTML file then looks like

<!DOCTYPE html>
<title>Title goes here..</title>
<meta og tags here>
<script src="/site.js"></script>
paragraphs of content goes here...

Good enough HTML for most browsers, and the site.js JavaScript will fill in the missing pieces as listed above. Note that I load the file in the <head> tag, synchronous to make the browser wait for it to load!


I have been considering leaving my current host, Loopia, since I don't really need their web host package, and it becomes a little expensive for what I use. Looking over the alternatives I wanted a European alternative if possible. Given the modest requirements I settled on Bunny CDN with a minimum monthly cost of €1.

The files can be uploaded to their storage product, and then layer their CDN on top and everything should be set!

After I configured and started to use Bunny CDN I also started to use Scaleway glacier storage for backups of our home computers. There's a clear upside to use only one of them, to have one less provider to manage. However, currently neither provides both cheap backup storage and cheap CDN functionality, so for now I will use both.

(Note to self: write a followup in 2034 and see how it worked out)

Victor 2024-02-23