MXIi

Ok, now this site is officially live. Time to write something. I’ll start from some details about site itself.

Initial idea was (long time ago) to use PmWiki as the site engine. I’ve used it before and I really like it. The main drawback that was bothering me - the complexity of maintaining blog-like site on a wiki engine. It is possible, but there are better ways to do it.

Then I discovered static site generators. There is not much conceptual difference between them and file-based wiki engines like PmWiki - bunch of text files translated into html pages with some rules, but on publishing time, rather than each time on site access. And it’s perfectly fine this kind of site. There even should be a way to use PmWiki as static site generator, if I remember correctly.

Looking for static site frameworks, I quickly discovered that there is a plenty of them. And there is a good choice of programming languages they are implemented in. As it was with PmWiki some time ago, I need to compare them and decide on optimal choice.

First of all, there are some sites existing to help with comparison - https://staticsitegenerators.net/ and https://www.staticgen.com/. Here you can look for available options and narrow list of them through programming languages, popularity and development status. I was looking something that can be used easily on windows machine, so I limited language list to C#, Python and Go. Since majority of static site generators are implemented in JS and Ruby, I end up with not too long list:

• C#
  • pretzel (github)
  • Wyam (github)
• Python
  • pelican (github)
  • hyde (github)
  • Grow (github)
• Go
  • Hugo (github)
  • gostatic (github)

I think I missed this somehow: Nikola (github). Written in Python. It looks promising, but I discovered it later when I already decided to stick with Hugo.

Then I took a closer look on each of them. In order of exclusion:

• Grow (aka pygrow) - looks interesting, but it is only for Mac and Linux, which is disappointing for a Python application.

• hyde - too sparse documentation, very low activity on github in recent years. pip installation failed.

• gostatic - looks very flexible. But there is almost no documentation, no community, no themes and examples. Low activity on GitHub. There is strange site https://gostatic.io/ - you need to register to enter, without any clue what is waiting inside.

• pretzel - jekyll reimplementation on C#. jekyll is “blog oriented”, so it will be possibly harder to do anything other than standard list of posts. There is some activity on GitHub, but nothing more than that. And you need to rely on jekyll documentation.

• pelican - looks quite good. I got some recommendations for this particular engine before. You can organize your content in any way you want. Lots of flexibility. Lots of everything. Actually, after trying to dive into all of that, I found myself uncomfortable with pelican. It has a lot of things I’m unable to keep track of, and it’s quite slow. Infrastructure is quite chaotic - while most of themes and plugins are tracked through specially-made GitHub repositories, a lot of pelican-related things are obtainable through pip. I need something simpler and better organized.

• Wyam - totally different beast to all of above. I would like to look at it closer later, but decided that it’s too experimental for this time. It wasn’t looking that great while ago, when I was making decision, but now it’s under active development.

• Hugo - overall acceptable. Flexible enough in a way you can organize your content, has community, not too sparse documentation, some themes to start with, reasonable activity on GitHub. So I decided to go with it.

Right choice?

It will do the job for now, but I’m not completely happy because of the way some things implemented (or not implemented) in it. May be I’ll consider Wyam later.

Hugo pros:

• easy to run on Windows - just a single binary;
• easy to see your work with built-in server and live reload function;
• it’s very fast;
• active community provides fast response;
• just enough flexibility and features to get working site quickly.

Hugo cons:

• confusing enough to prevent you from getting properly working site quickly;
• documentation is somewhat chaotic and not as detailed as it may be, some functions undocumented;
• you will soon discover that flexibility is limited - some things hardcoded, no content includes;
• low rate of releases, no night builds - it may take a while to get a binary with important bug fixed (luckily it’s quite easy to build from sources).

What’s next

For further details on running Hugo site check the project page. And follow this blog to keep track on updates.