I’ve since realized that Hugo’s architecture provides a variety of template optimization strategies. Hugo builds pages concurrently, so it might be hard to see on a modern device but before partialCaches or module mount trickery — there’s still the implicit complexity of the output/lookup model.

Generally the complexity cost of the default output formats are: page > term > taxonomy > section > home. Keeping expensive calls inside a section and/or a home template is usually optimal. i/o and maybe memory should be the only problems with lots of pages.

The blog linked in a previous post is a gem. Too bad the current site doesn’t appear to have all the archived posts, you need strong search–fu to find them on archive.org.

Reverse pagination is a counter–intuitive strategy for attempting to make links immutable/cacheable and bookmark friendly across older pages. I searched for a visual explanation (difficult to explain concisely) and eventually arrived at an old article on paging apis. Reverse pagination has its gotchas, but then again pagination itself is one big gotcha.. :-) Well, it depends on the use case really.

Here’s a muse; linking to external sites is probably one of the harder parts of blogging. Pages can go 404 and you won’t know exactly why, urls change even though they’re supposed to be immutable.

To blog while having pointers to disparate sources requires checking for dead links, and verifying that content relevancy hasn’t changed. The solution is to either archive everything (hard) or to not link at all (easy). High mutability is one reason why people take pictures of online content — it just works.