A few years ago I decided I had enough from some application using lots of memory on my memory-strapped server to show some simple web-pages. So I went on a hunt for “something else”. Mostly a generator for a static website.

There were many, many, many candidates, but many of them fell through for me because they:

• were too difficult to use
• had some weird macro language (in some cases even Ruby with Textile, which I know from my work and which is an instant candidate killer for me)
• were written in horrible programming languages (I suspect I’ll have to fix some other peoples’ mistakes, and I’d rather not do that in Perl, Javascript, Haskell or something like that)

The final list of candidates consisted of just these three:

• pelican - a bit weird, but uses standard Jinja
• nikola - a bit better, but also a bit more obscure
• hugo - what I at that time thought was best

So I chose hugo. That is all well and good, but lately I just get messages like these:

ERROR render of "taxonomy" failed: template: _internal/_default/rss.xml:3:9: executing "_internal/_default/rss.xml" at <site>: can't evaluate field email in type string
ERROR render of "term" failed: template: _internal/_default/rss.xml:3:9: executing "_internal/_default/rss.xml" at <site>: can't evaluate field email in type string

I just don’t understand enough about the inner workings of hugo, and the interaction between the template language, the configuration and hugo itself is a mystery to me. By googling I see this has been a problem for years, and the answers also show me there’s no easy way out of it. My template just 150% broke into pieces, and btw. when there’s an _internal there it isn’t even my template, it’s the inner workings of hugo itself (or something like that)

So, what to do, what to do. I was fed up with hugo’s way of implementing new features in the template anyway, but I was very sure I didn’t want to leave markdown. After trying pelican again I ended up choosing nikola, we’ll see how long that will work for me.

Templates in nikola are either based on their own macro language(?) named “mako”, or the more accepted (at least in the Python world) jinja2. Implementing dynamic content is easy as having either {{-}} around a variable (the variable evaluator) or {%-%}-blocks. Btw. this is an example where I am actually trolling nikola to do a “Textile” on me.

There’s one bug I have to fix before going live with this, and that is the “blacking out” of code environments. It seems everytime I use code, by single-quoting, I get a smaller font and black-on-black text. I don’t want visitors to have to mark each and every code segment just to see what it says. Also, the font should be the same size, and at least readable. Besides, the background colour right now is hideous (darkslategray), and the selection colour makes the selected text unreadable (light gray text on very light blue, #b3d4fc).

Some kind of a build system would also be nice, but for now I think I can remember nikola build and nikola deploy.