In my last post, I said that I have moved to Zola from Wordpress. In this post, I thought I would share a few reflections about how that went.
I had decided up front that I was going to move to a static site generator, because of the flexibility that this gives me in terms of the site hosting. I quite wanted skmething fast because, well, fast is better than slow. I looked a Hugo which is a main contender in this market. It looks nice, but I found the documentation unclear. In the end, I went for Zola because the documentation was pretty clean. I also liked it because it is implemented in Rust and I know how to code that and this is often useful with any tool that you are using. My main worry was that Zola has an “all in one binary” ethos; I can see why this is important, but it also means that it’s effectively unextendable except through templates; what you see is what you get; so, perhaps, my Rust knowledge was rather irrelevant in this light.
In use, I found that it did largely do what it says. It’s simple to get running, it produces a nice website. The metadata and text input is all markdown so relatively simple and straightforward. I thought my Rust knowledge was going to be useless but, actually, I did need it because I needed to hyperlink between anchors defined in html which Zola wouldn’t do otherwise.
The main drawback is that Zola is not as rich an environment as Wordpress and cannot be freely extended other than with it’s own template library. For example, in Wordpress, I had kcite for building reference lists. It was obvious that Zola templates were not going to be enough for this, so in the end I prompted for a hybrid solution. The markdown that Zola processes is all actually generated using pandoc. This somewhat negates the point of having a fast processor, although that’s still good if I change the template. I guess I cannot criticise Zola for this; it’s meant to support a certain kind of website and the academic extensions that I have added to Wordpress are not widespread requirements.
This also impacts on the authoring experience; for example, several themes add KaTeX support. From the web side, they do this in more or less identical ways, but author side, turning the functionality on uses different configuration. I am not entirely sure how this could be addressed, but it does seem to me that adding something like wordpress plugins could work. These would add shortcodes and tera macros, but no actual themes files; this means that themes would need to support a given plugin. It would be possible to generalize this, though, by adding some standard hooks that could be called by a theme to support multiple plugins.
Alternatively, I could just wait till someone produces a theme that I like and has the functionality I need. This might be the easiest solution!