I'm going to try to re-implement part of ikiwiki. It's my third attempt, so the likelihood of failure is high. I'll blog about this for general amusements. "Software development as a comedic performance", if you will.

The name of the new program is riki: it's part of ikiwiki and it's written in Rust.

Motivation

I've been using ikiwiki for wikis, web sites, and blogs for about two decades. These days I only use it as a static site generator. I like it. I've grown comfortable with it.

I've tried several other static site generators, and I've written one myself, but I've not liked them.

Some of the reasons I like ikiwiki are:

the power of the inline directive is astounding; it's how an ikiwiki site creates a blog, but I use it also to collect pages by tag, or by location on site, or by other criteria; this is very flexible and lets me do some things basically no other site generator has enabled me to do
much of the power of inline comes from the PageSpec mini-language for selecting what pages to include
in the generated HTML for a site all internal links are relative to the page where the link is; this means the HTML isn't rooted at a specific base URL, and I can easily move it elsewhere
in other ways too, ikiwiki gives me as the site author the power and flexibility to do what I want to do, it is not opinionated; an opinionated tool is great if you share its opinions
there is a 1:1 mapping of input files to output files in their respective directory trees; I get to organize things in whatever way makes sense to me

However, ikiwiki is of course not perfect:

it can be slow; my biggest site is many thousands of pages, and can take up to about twenty minutes to build from scratch; that doesn't happen often, but it happens often enough that it annoys me
on a first build, on a fresh Git checkout, ikiwiki gets timestamps of pages wrong, unless you run it with the --gettime option, which makes the build process even slower
to enable speedy incremental builds you have to manage the .ikiwiki cache carefully; this complicates things and I keep making mistakes with it
page templates are powerful, but also clumsy, and it takes a lot of work to style ikiwiki output more than a little
ikiwiki is too forgiving of errors: for example, if an internal link is to a page that doesn't exist, the site build doesn't fail
ikiwiki is written in the Perl language, which I don't know much, and that makes it hard for me to make changes

Riki

What I'm aiming for with riki:

only a static site generator; I have no interest in riki being a wiki or otherwise support editing via a web browser
speed; in my initial prototyping on that largest site of mine, a single-threaded Rust program processed it in less than ten seconds; this is fast enough that I don't care about caching or incremental builds
intolerance of errors: if there's any problem in a site (bad link, wrong date format, etc), fail the site build
as much of output styling as possible can be done with CSS only and the provided default CSS is acceptable to me
hackability by me
ikiwiki compatibility for the sites I have; I'll be happy to review patches for additional features, but I'm unlikely to implement directives that I don't use myself, for example

I'm happy to consider requests for ikiwiki supports I don't use myself. I cannot promise to implement any of them, but I can at least promise to discuss them, and to try to structure what I do implement in such a way that it'd not be too invasive for someone else to implement the desired features.

I use Radicle, and the riki repository is already public. Radicle is a bit of a leap for most people, so if there's demand, I can make a mirror on codeberg.org. Until then I'm happy to receive issue reports via email, or patches (something that I can feed to git am) via email. Or any other channel.