Twenty-Four Years Of Wiki Engines - Tao of Mac
Rui Carmo
Tao of Mac
Aug 2nd 2026 · 8 min read
·<br>#github #go #python #sashimi #site #sushy #yaki
Twenty-Four Years Of Wiki Engines
Yesterday morning I switched this site to its fourth major engine, a little over twenty years after sketching out the core idea behind it. The new generator is called sashimi, is written in Go, and runs almost entirely inside GitHub Actions–which is mildly amusing because the first Sashimi, in 2006, was also meant to batch-render this same filesystem tree using dependency tracking.
Reusing the name is… confusing, but it fits my overall theme, and the underlying concepts have held up rather well.
Always Has Been… a Wiki
The site has always been a Wiki disguised as a blog, and I’ve been fortunate enough that its content has outlived every engine underneath it.
With this post, there are now 9,287 source pages: 6,640 in Markdown (after a ruthless campaign of LLM-assisted format conversion that converted around 3,000 while preserving the content verbatim) and 2,647 older files still containing a mix of Textile, raw HTML and assorted historical quirks, with images and other attachments stored alongside them.
PhpWiki (2002-2007)
I’m still somewhat amazed that I hosted the site from home for around five years, running PhpWiki. It was weird enough to run a conventional PHP Wiki backed by MySQL, but I ran it on Windows NT for at least part of that time (I forget exactly when) and I hacked its themes and plugins extensively.
But it was essentially an on-demand server–requests, rendering, editing and storage still went through an application and database stack, with varying degrees of caching.
Every PhpWiki page view traversed the web application and database stack.
In retrospect, it’s a wonder it worked at all, but it both spoiled me and made it obvious that a conventional CMS would never fit my needs. Around 2005 I decided to switch to Python, and a year later started a thing (also called sashimi) to try to build a lighter, raw engine, but it never really went anywhere because I realized I could leverage Snakelets to build a somewhat less half-baked solution.
Yaki (2007-2016)
Yaki replaced the database with plain files, fixing my annoyances with PhpWiki’s versioning, database maintenance, and a bunch of other gripes (cof cof PHP). It was a dynamic Python Wiki engine running on Snakelets, with pre-rendered HTML, aggressive caching and a filesystem content store–all finely tuned for the days when this site lived on hardware where every megabyte and system call counted.
The biggest improvements for me were around ease of publishing–durable metadata moved to the filesystem, I could use “proper” markup, semi-automated Wiki links, backlinks, generated tables and feeds, and I had Dropbox running on my VPS, so publishing was instant–I only needed to fire up vim, draft and save, and it would be indexed and go live as soon as the metadata allowed for it.
Yaki was the first engine where I decided that markup was a second-class citizen–I didn’t care what format content came in, since it was all rendered into HTML and transformed using an lxml pipeline into the finished page.
This not only made it possible to go way beyond the primitive PhpWiki plugin system, it also gave me full control over the output, allowing me to render tailored mobile content depending on what kind of browser visited the site. Yeah, remember WML and WAP?
But it also gave me proper full-text search and full control over HTTP caching, which became more and more important as I had to deal with the occasional Slashdotting:
Yaki separated indexing and pre-rendering from its fast cached request path.
Its biggest downside was that it accumulated enough custom rendering behaviour to make moving to a conventional static generator needlessly painful. For instance, I tried Hugo more than once, but its assumptions about content layout, images and markup never matched mine, largely because I am a staunch believer that a page is not just the markup but a bundle of the assets inside it, and the vast majority of site generators just dump images into an assets folder and never bother ensuring that you can reorganize your content logically.
In short, none of the static generators I tried could, ironically, really scale beyond a few thousand pages and still allow me to manage content sanely, And given the huge content tree I had built over the years, I was not about to refactor thousands of pages just to fit someone else’s opinions about how a site should be structured.
It would always have been more work than maintaining the code I already had–especially since preserving URLs and permalinks dating back to 2002 is one of the few parts of this exercise I take very seriously.
So that never really happened.
Sushy (2016-2026)
Yaki replaced PhpWiki in May 2007 and ran the site for nearly nine years. But in April 2016 I replaced it with Sushy, initially written...