History
In 2013, I started my website, using Hyde.
In 2016–2018, I reimplemented the site on Lektor and redesigned it twice (including migrating all content, which was actually fairly involved in at least one of the designs), but decided I didn’t like the direction and never shipped it (although it was genuinely finished).
In 2019, I migrated to Zola, making various changes but keeping all content.
I kept on writing various things over time—I have a bunch of half-finished draft articles and a very long file of stubs in various stages of completion—but found the bar of polish I’d set to be too high, and didn’t end up publishing much.
I became fed up with Zola, the constraints of other people’s static site generators, and the traditional structure of my site altogether.
In 2026, I’ve decided to archive all the old site and content, because I have a significantly different vision of what I want now.
Existing URLs of all public resources (HTML, Atom, SVG) and most subresources will continue to work, but at least for now they won’t be integrated with the new site, and may never be updated.
I’m abandoning all /blog/… structure (/blog/, /blog/slug/, /blog/tags/slug/{,feed.xml}).
/feed.xml will continue to work, redirecting to its new name /*.feed. I have archived all the existing feed items to a second page (it had grown to 425 kB and was possibly my most-requested file), and I will probably paginate my feeds more in the future. (I don’t know how many feed readers support pagination, but the content normal people want to fetch will always be on page one, so it doesn’t matter anyway—it’s more a foolish perfectionism that has me keeping all content theoretically accessible through feeds.)
Theming is implemented differently now, and I decided not to migrate settings transparently (it’d slightly help a very few people, at a small cost to everyone). I patched the old site to read the new settings, but I removed its theme switcher out of laziness.
New direction
Structure
Old site: other than a few undated pages of special purpose (e.g. /about/, /hire-me/), all content was in /blog/slug/. I used a single taxonomy, /blog/tags/slug/.
This exposed a philosophical aspect, too: almost all was blog post, private until complete, then published, with minimal updates (only for corrections or changes like updating rustc output—rust-fizzbuzz was the most-updated by far over the years, as rustc changes several times required more extensive updates, because it broke a point that I was making, due to introducing non-lexical lifetimes, or automatically hoisting temporary values, or no longer mentioning lifetimes in some error messages—several changes that improved the language and the beginner experience, but at a significant cost to mental model pedagogy, quite possibly making it harder to become expert). Overall, it tended toward append-only.
New site: I want to play with a different approach: no more tags/categories/taxonomies, I’m aiming for a directed graph with edges powered by link relations (<link rel> and <a rel>). This is more flexible than mere tags: you get subtags (up), series (prev/next/first/last), and tags are themselves pages in a more real sense than with tags (even though I already made my tag pages more custom than most ever do, fighting against Zola to do so).
Also, it’ll be a bit more reminiscent of a wiki. Often editing existing content rather than appending a new blog posts. A lot more small pages and interlinking. Also publishing incomplete stuff, so marked, and stuff in different stages of polish.
(A lot of this architecture has been implemented, but the full implications are not yet apparent mostly due to a lack of content.)
URL styles
Old URLs all ended with a trailing slash, and were mostly /blog/slug/.
New URLs are, at least for now, entirely flat, just /slug. I may introduce other patterns in the future.
Thus / itself was the only conflicting URL, so I moved it to /pre-2026-index.html.
Hierarchical URLs work well when your structure is tree-based. Mine is not going to be, any more. Many pages will definitely have a primary parent, but at least for now I don’t want that to influence URLs.
I considered timestamped URLs (such as /2026/04/07/2026-website), but decided against them. A lot of content will not be dated, and the dividing line between dated and undated content will not always be clear and may change.
How preferences are stored, and the implications
Settings previously used Local Storage. Now I’m using cookies for a couple of few reasons:
Dev mode (which I’ll get back to below) has to be a cookie, so the server can send back a different response from the same URL. (Alternatives: serve content from multiple URLs, or depend on a service worker that proxies requests, adding an extra header when in dev mode.)
I want it to work as completely as possible without JavaScript. It’s easy enough to lean on :checked to change styles with only CSS, but you can’t persist them without either JS or a form submission that returns cookies.
Earlier on I was also thinking about the most reliable ways to avoid a Flash of Unstyled Content (FOUC; most notably, a brief flash of white background when in dark mode), and that the approach I was formerly using required the prefs elements and scripting to be early in the document, whereas I’d like to shift them after the content, but I ended up realising that, without persistence and thus with JS permitted for applying prefs from local storage, there were alternatives to the way I was doing it.
In the end, it’s nicest for the client if the server sets the load-time preferences in <html class=… style=…>.
The Caddy configuration and templating to support this isn’t too bad. My loosely-golfed JavaScript, however, is: partly deliberately so, even though the main reason I shrank it so aggressively was because it had to be early in the document at that time (I only implemented the server actually filling in the prefs on root attributes in the day before publishing).
Then the prefs elements and styles and all can come at the end, which is especially best for browsers that don’t support <dialog> or popover (old browsers, and all current text-mode browsers that I know of).
I have Ideas.
🚧 Under construction 🏗️
Do you remember those “under construction” banners and GIFs of the ’90s (loads 941 images totalling 9 MB)? They tend to depict a work site and the notion of caution or danger.
A building construction zone is a dangerous place: there will be things to trip over, fall into, and have fall on you.
Children may still want to play there, because things are interesting.
A website construction zone is a place where you can safely poke and prod.
This site is very much under construction. Come take a look! view-source: everything! Have fun!
Oh? You say it all looks minified? Turn on dev mode in the (or set the cookie dev=1 by some other means) and the server will give it to you unminified.