New website!

By Patrick Wigmore, 6 July 2023, published: 16 July 2023

Regular visitors¹ will notice that things have changed around here. Where previously there was a single page, now there’s actual content and navigation links!

I’ve been building a Hugo template so I can generate nice-looking static web pages based on a set of content files written in Markdown.

You’ll notice that some of the content is much older than the actual website. I’ve been saving it up for years, and now I’m working my way through the backlog to get it looking nice enough to publish.

I’ve:

• Learnt Hugo (Build Websites With Hugo was helpful)
• Devised a site structure
• Generated some HTML
• Written a whole bunch of SCSS
• Made some icons
• Thrown together a placeholder logo, and then grown to like it
• Fussed about responsive design
• Chosen some lovely fonts (Inter and Fira Mono)
• Fiddled with image sizing
• Spent way too long finding a tidy way to render maths

But, on the whole, it’s gone pretty quickly.

The visual theme is vaguely inspired by paper documents, with a recurring theme of putting stuff in little boxes with rounded corners. I’ve always rather liked those. Rounded corners seem to be in fashion right now, but I was into rounded corners before they were cool. I’m just doing what I like and hoping it comes out looking vaguely presentable.

I hope you like what you find here!

Some esoteric constraints

It’s my site, so I get to set a few ground rules for how I’m building it:

• It’s a static HTML site; no server side code
• Very strong reluctance to use any client-side code either
• No resources or services loaded from third party domains

It’s a static site because that makes maintenance and hosting less of a burden. I don’t need to worry about finding a security hole in my PHP or my C# or whatever I might have used, or installing updates for a third party framework. The Hugo template just needs to spit out valid HTML. It doesn’t need to worry so much about input sanitisation or error checking or efficient use of CPU time on a server with multiple concurrent users.

I’ll avoid client-side code because this is fundamentally a collection of documents, not a web app. Not putting JavaScript into it makes it feel clean to me. Plus I don’t need to worry about making sure my JavaScript functionality gracefully degrades if the browser doesn’t run it.

And, in a Web full of trackers and browser fingerprinting and seemingly every site being served with a side of tech giant, it can be nice to see your browser connecting to just a single domain. (Though, to be clear, I am using a web host. This isn’t just running on an old laptop in my attic, I swear.)

Some people browsing the Web block some combination of Javascript and/or third party domains on a site-by-site basis. When it comes to my site, I’d like to save them the bother.

Consequences of such constraints

These ground rules do make some things slightly more difficult. I can’t just bung in a third party JavaScript library from a CDN and magically get pretty maths, for example. No, I’ve got to render that sort of thing in advance, as static content, before I even upload it to the server.

And, by not loading resources from third party CDNs, I’m not taking advantage of visitors’ browser caches, which may well already contain some of those resources.