Motivation for riki

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 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, or by other criteria; this is very flexible and lets me do some things basically no other site generator has enabled me to do
• in the generated HTML 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 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 process even slower
• to enable speedy incremental builds you have to manage the ikiwiki cache carefully; this complicates things
• 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

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