This is going to be a special single-issue edition of the week notes: all about archives. I talked about it a bit last week (Dependencies; End of Year; Templating engine; Interactivity) and the trend continues. We shipped a good amount of preliminary changes this week and the feedback has been very, very loud. And good!

It's a funny thing:

• Sometimes you spend a couple hundred hours in aggregate working on a feature or system that you know going in is only really used by two or three percent of your user base.

• Sometimes you spend a hundred hours in aggregate working on subsoil-level systems that are completely invisible in terms of user experience but vitally important.

• And then sometimes you spend five or six hours working on archives, which, despite their attach rate in our user base, are somehow perpetually neglected—and in those five or six hours, you get more positive feedback than the rest of the year. (That's an exaggeration, but not by much.)

One of the things that we (and I) need to get better at is reducing the number of eggshells in the omelet, so to speak. The last time I remember this was when we rolled out the Firewall—which is funny to refer to as an act of the distant past, as if it was not six months ago (my, how time flies!) When we make these sort of big, sweeping changes, it's really hard not to leave a couple rough edges. They get sanded down extremely quickly, but result in some customer pain in the interval.

On the one hand: some of this is endemic to scaling a nebulous system with infinite surface areas (UGC for the firewall; CSS for the archives.) It's simply too difficult relative to effort to explode out the number of potential states and edge cases that our previous implementation had, especially given the proliferation of custom CSS.

One thing that folks had written in that does hold water, or at least has stuck in my head: is that they wish they knew we were going to do this. All of our changelogs are backwards-looking; we don't do a lot of "breaking news — we're gonna change some stuff soon." Maybe that's worth revisiting.

(There are some things about this engine that mean this will be the last suite of breaking changes ever — but that’s a topic for early January.)

The shape of our theme engine will be as follows: a collection of HTML templates arranged and named in such a way that hints at file-based routing. For instance, a classic theme would be:

index.html
archive/index.html
archive/[slug].html

We have no plans on actually doing file-based routing yet, but this seems flatly simpler than having to standardize on a different series of names and expecting ourselves and our users to keep the map in their heads. Alongside these templates sits a single CSS file—we can revisit this if we need to down the line, but enforcing a requirement of one CSS file feels like a good way to simplify our build chain dramatically—and a package.json file containing top-level metadata, configuration, and supported design tokens for the theme.

Taken together, you get:

templates/index.html
templates/archive/index.html
templates/archive/[slug].html
assets/styles.css
assets/package.json

(One small bikeshed in all of this that is not particularly dramatic or load-bearing, but I do want to call out: we're going to shift the public archive page and subscribe pages to essentially just be a "page." That is, unify their backend logic and context such that the only difference between the two of them is the template that they render. This is more or less the case today; if you were to look at the two views, they're functionally identical. What this allows us to do is build with an eye towards letting themes have custom arbitrary standalone pages in the future, while also just lowering our overall rendering footprint.)

As we launch this new engine, the question of what themes to build to show it off is a natural one. There shall be three:

1. Arbus, named after Diane Arbus—an Instagram-esque theme, the most self-explanatory, as we've long known the need to have a more image-forward theme. This will be very similar to the modern theme, except with an archive page that heavily features images. (In fact, we need to double-check that this needs to be a discrete theme at all and can't just be implemented via design tokens.)

2. Carson, after Anne Carson—a more experimental theme, a riff on Blot's lecture template, meant to obliquely suggest the flexibility the new theming engine gives us, with a design style less obviously equivalent to our existing themes.

3. Lovelace—a completely brutalist and "unstyled" theme meant to be evocative of very early 90s websites, rounding out the bunch.

Together with the two existing themes, this gives us a corpus of five total themes that are not complete in and of themselves but represent a good smattering of various things our theme engine can do. (I reserve the right to revert the cutesy names to something a little more simple, but… that feels somewhat lame.)