I did it again. I changed blogging engines again. I was running Astro, got tired of it and wanted to use something else. So here we are, with this fully statically generated blog, using Zola. And I guess a few more surprises.

What's wrong with Astro?

Nothing. At least not for what it does and compared to its competition.

I guess my issue boils down to the fact that it's a Javascript framework with everything that implies. Between a cavalier attitude towards dependency creep and frequent breaking changes, it proved to take more of my time that I was comfortable with.

I still believe it's a great framework that is a step in the right direction for the modern web, and incentivises a static-first approach while allowing for all the bells and whistles of Svelte, Vue, React, or others.

The last major update I did took me a few hours split accross multiple days and I had to replace a build plugin with a shell script. I got tired and needed a change.

Zola, the good, the bad, and the ugly

So here we are, I switched to Zola, Rust-based, compiled and available through my distribution's repositories. It's also a fully static site generator, which is a kind of tool I hadn't used since the last pre-Astro version of this bog with Coleslaw. If you read my previous rewrite article, you'll notice that it was also a major compatibility-breaking update that made me move the last time.

Ultimately, I'll never be satisfied until I write my own bog generator. In the meantime, Zola felt like a comfortable change, which fits my needs in some areas and is more distant in others.

The good

In truth, despite the dramatic subsection title, it's overall pretty good. For the best parts, it's easy to install (for me) but I don't think compiling it would be much of a hassle. It's… blazingly fast. Sorry.

I was also extremely impressed by Tera, the templating engine used by Zola. Please don't compare it with say Vue's templating engine but more with a Jinja or a Twig. We're not rendering pages on the fly, but statically compiling them, so of course it'll do less than Vue's. However, I think that's the first time I ever saw some sort of [component] in that kind of template. It's limited but it's the only example I've ever seen, which is enough to impress me.

Another aspect I quite liked was the filters which kind of feels like piping your variables through a series of filters.

Here's a real example where I turn my article tags into a comma separated list for "SEO". I'm pretty sure they've ignored keywords for at least 10 years or, worse, dereferenced websites because of them. Listen, maybe the reason why I can affort to pay my hosting is because crawlers mostly ignore me?

tags | join(sep=', ')

Or a very terrible way to get a file's name and extension. Don't worry, I choose those files names and am only i because I'm in a loop.

i | split(pat='/')[-1] | split(pat='.')

Aside from Tera, content is markdown files with a front matter metadata header. I can't quite pinpoint who came up with it, it's in the big static generators like Hugo or Jekyll (used on Github pages). And thankfully, you can use TOML instead of having to suffer through YAML.

It's also pretty easy to make listing pages for your collections of articles, called sections by Zola.

You can also have little pieces of data that are easy to manipulate called taxonomies which I guess are aptly named. Zola will also generate feeds, a sitemap, and a lot of other things I'm not using.

The bad and the ugly

As I said earlier, it's a focused tool and limitations I'm encountering might be more of a case of me wanting more than Zola's (or Tera's) fault.

I had wished that there was a way for Tera component to access the page's (or the section's) metadata. I'm usually not a fan of global contexts, but when that data is already available in the template's, it doesn't feel like a stretch.

I would have also liked if there's was a more elegant way when writing a template file to know whether you're in a section index or a page. For now, I'm basically having to check if a page variable exists as part of the context.

I would have also like if you could have used conditions inside of other structures like an assignment.

Here's an example that exemplifies both where I assign two variables. Please disregard the use of a global, I'm using the same variables later in another block.


{% if page %}
        {% set_global title = section.title ~ " - " ~ page.title  %}
        {% set_global description = page.description  %}
{% else %}
        {% set_global title = section.title %}
        {% set_global description = section.description %}
{% endif %}

Now, as for Zola proper, I wish you could define multiple sections without having them impacting the path. You could separate content to remain organized without reflecting that on the user.

I also wish you could declare HTML content for some special pages. Right now I have some empty content markdown files that are only there do choose the name of the path and maybe set a variable or two.

I also needed to check the forums and Github issues quite a bit to scope out what I could do and what I couldn't do. I was able to achieve everything I wanted though, so information was available in the end.

I wish you could add hooks and scripts to Zola. For example, I used to pre-compress my files with Gzip and Brotli so that my server just has to serve them. Files are static, there's no need to re-compress on the fly. A hook running after the build command would be great. I also wish you could run arbitrary scripts like you can with npm (and "friends"). In both cases I can just call shell scripts, it would just be more convinient.

Although this section is longer than the positives, all those are minor, I'd still recommend Zola and/or Tera.

Bits and pieces

I don't have any place where to fit those so here's a few things that may inform your understanding of my opinion.

I don't use Sass on personal projects so I don't know how pleasantly integrated with Zola it is. If I'm at work, I'll use a css preprocessor (or analogous techniques) but my style volume just isn't enough to add a transpiling step to my setup. So all the css is handwritten, so is the html.

The only taxonomies I'm using are my tags, which aren't especially useful considering how many articles I have written but maybe that'll come in handy in 10 years.

I'm not using the default robots.txt nor am I extending it. I just carry around the one I've been using for a while.

My favicon is hand drawn by myself with Inkscape and my mouse. If you know simpler vector graphics software for the uninitiated, please let me know, I feel I need to look how to do anything when I'm using it.

I re-did my whole design and even re-designed some pages like the index. In the upcoming hours/days after the deploy, I'll check the bog with scanners to see if I don't have glaring performance, accessibiliy, or standards compliance issues. If you notice anything, please let me know.

In the same vein, some ressources like my sitemap may have moved as part of the migration. I will strive to apply the pertinent redirects but please also let me know if you notice anything.

Conclusion

Overall, I did enjoy my time porting this bog from Astro to Zola. Everything feels a bit leaner, less complex. My tooling is simpler. The update process is simpler. Building is faster. My templates are also smaller.

I've been busy but I still love writing and I will write again. In the meantime, my desire to make my bog prettier and easier to work with will have to suffice. But maybe next time I'll be the one reading your work.