No node_modules, No Regrets

I love Go. Not only the language, but the mindset and philosophy behind it: keep things simple, and it comes with batteries included. Its standard library reaches so far into what you actually need that you can build real things without reaching for a dependency out of habit, or out of necessity. I wanted this site to be built the same way, so I set myself a single rule and kept to it: no npm, no bundler, no build step beyond go build.

Obviously, packages aren't an "evil" thing that must be avoided at all costs, but they should be very carefully considered before incorporating into the code. In this site I use a handful of small Go packages during build time to transform Markdown into HTML, thumbnail image generation, font loading, and to generate minified HTML/CSS/JS/JSON files for performance reasons.

The site is a static site generated by a small program I wrote in Go. The content lives in Markdown files. goldmark turns that Markdown into HTML, and Go's standard-library html/template package stitches the pages together. The output is plain HTML, CSS, and a little JavaScript, files a browser reads directly, with no server standing behind them. Every dependency is written in Go, so the whole toolchain is one language and a handful of well-chosen libraries. There is less to break, less to keep current, and, a year from now when I come back to add a post, less that I will have to relearn.

I had watched too many side projects quietly rot. Not because the code failed. The code sat there, patient and unchanged. It was because the build tooling aged faster than I, or others, could tend it. A node_modules folder that installed cleanly last spring now spits out a wall of peer-dependency warnings, and an evening meant for writing is spent placating the tools instead. A pure-Go generator has none of that weather. The toolchain is just the Go compiler: stable, fast, and it does not drift. There was a plainer reason too. I did not want to pay rent on a website that mostly sits still. A static site is just files: no application server to pay for, no database, no runtime to scale. It can be hosted for pennies, or for nothing, and asked to serve traffic while I forget it exists. It also comes with the added benefit of security. If there is no data storage and no server with complex logic, you're less vulnerable to attacks -- not that I foresee any on a portfolio website, but the principle still stands.

The speed comes almost for free. The pages are pre-rendered, so there is nothing to compute when you arrive. The HTML is already there. On top of that, the generator minifies the CSS and JavaScript at build time, preloads the fonts, and generates the social-preview images ahead of time. It even pairs each web font with a metric-matched system-font fallback, so the text does not lurch when the real font finally loads. All of it fits in a couple hundred lines of Go rather than a pipeline of plugins.

There is an old counsel that fits this quiet, unhurried way of building, where the aim is not to impress but simply to do honest work with your own hands and let it stand:

and to make it your ambition to lead a quiet life: You should mind your own business and work with your hands, just as we told you.
1 Thessalonians 4:11

None of this is clever, and that is rather the point. The dull tools, chosen deliberately, are usually the ones still standing when you come back to them.