Foolish constraints: My blog setup

Published: 11 February, 2024, updated: 11 February, 2024

One request (mostly)

If you’re tech-savvy, open up this web page in your browser’s inspector, and head over to the network tab. At least at time of writing this, you should see a single request. Which is not a common sight on the Internet today.

But there’s the image above? And a few other icons around in the header and footer? What gives? What about the JS/CSS?

Simply, everything that’s needed is in this single page. Every resource is embedded - either a vector format with text source code, or using base64-encoded data URIs for the image above. This page is around 47kB uncompressed with all its resources; compressed, it is around 22kB.

Conventional wisdom is likely that since there’s a decent amount of shared content between pages, we should bundle those separately, and then browsers can cache the results. It also says that we should separate out the images so that the browser can render the page, and those slow images can be fetched asynchronously by the browser and placed in the page when done. We don’t want to bloat our web pages with redundant content. We don’t want head-of-line blocking on one of our images to block viewing our page…

I do apologize for the literally 10s of people who may read my content in or after 2024 using a browser that doesn’t show images on a low-bandwidth and also low-latency connection who might be inconvenienced for more than a few 10s of milliseconds because I’m sending them data they aren’t going to render.

More seriously, I probably won’t consistently use this trick for images in blog posts - it’s quite reasonable for these to come separately from the other content, allowing the content to load.

But for CSS and JS, and the site “chrome”, I do rather like having it all in a single bundle along with the content. It certainly makes the job of the Internet Archive easier - along with anyone else (maybe me, in the future) to archive pages.

One other thing is quite obvious from there just being one request - there’s no third-party tracking (“analytics”, if you prefer). Mostly this is me being averse to tracking in general, and a tiny piece of this is that it removes the most accurate form of analytics I might be interested in looking at. It’s hard to fall into the trap of fixating on how many people read what you write if you literally can’t tell.

(Yes, there is the possibility of server-side access log analytics - maybe I’ll write about that another time.)

Minimal

While minimalism isn’t entirely correlated with simplicity, in my experience complexity is often easily avoided by just not doing something. In almost all cases, adding something increases the surface area of what needs to be kept in mind - and I have a small mind. Also, it means I’m less likely to run into a situation where my one-request policy above leads to a single 1MB file…

So just posts and an index page, basic and largely static header and footer, and text-dominated content with the occasional image.

I’m definitely a sucker for a well-placed and tasteful sidebar and some inset graphs or photos with captions and some well-crafted typographical architecture. I could be convinced that a photo carousel is a good choice in some scenarios. So I’m not ruling out something beyond plain old text and image tags…

Javascript-less (mostly)

For some time, having some JavaScript on a page was assumed - it was a necessary piece of at least some cross-browser consistency for some relatively basic features. But since Chrome started supporting MathML last year¹, the most compelling reason I had to include JavaScript in my pages (to polyfill MathML support for Chrome) disappeared: $a^2+b^2=c^2$(Now if only Hugo supported inline LaTeX in its Markdown…)

So no JavaScript needed right now. While I plan to likely put more “playground” stuff on a separate site, I might still want to use things like interactive graphs or data explorers², but I’ll cross that bridge when I get there. And it’ll only be on those pages that need it.

Minimal CSS (and no CSS frameworks)

Blogs are primarily text and secondarily images and tertially³ tables and sidebars and blockquotes and such. No need for a lot of CSS, and certainly not some complex CSS framework.

CSS is definitely the area I find the most convoluted in web development, so I’m happy to keep it as minimal and straightforward as possible. Each piece of CSS in isolation is relatively easy to understand - it’s really when they get put together…

If you’re going to have $n^2$interaction complexity (or more likely a lot worse), best keep $n$small.

Minimal markup (with some semantic markup)

For similar reasons to the above, the reduced set of needs for blogs also reduces the need for additional markup. A hundred or so DOM elements, with a maximum DOM depth of 9, is a walk in the park for any device manufactured in the last decade.

It would be easy to be faced with potential solution for styling that added another wrapping element and just to accept it, but it’s way more fun to try figure out how to get away without adding more than the minimum semantic set of elements. Alternatively, if it’s not looking feasible - is that bit of styling really worth it?

Dark/light mode (colorscheme)

The one “feature” I could have left out as part of that minimalism, but that I really wanted, was supporting dark and light modes for the pages. I much prefer dark backgrounds⁴, but I understand that others might prefer them light.

Thankfully, this is fairly easy to support and test - so long as you’re not particularly discerning about your colour choices⁵.

Constraints… something something… creativity

One argument I considered multiple times as I failed to start blogging again between 2009 and 2024 is that I was making it more complicated than it should be. I should just use Wordpress or Blogger or whatever. I shouldn’t write my own blog engine and my own theme, and so forth.

I tried that - I have had multiple of those sites set up too. And they surprisingly didn’t last nearly as long as those when I was doing it all myself. For the others, part of the ritual was getting this content to look right - to implement some missing feature. Sometimes I’d be building something, and then wanted to write - and I had it right there open in front of me.

One big difference between 2003 and 2024 is that my “computer” isn’t my primary personal device any more. And perhaps it should have been obvious that I wasn’t having trouble writing at work where a computer is my primary device…

So, maybe part of my 2003->2009 run’s longevity was that I was building things myself, largely from scratch. And part of that was having constraints⁶, and also having this minimalist and personal aesthetic. So back to that, I guess⁷…