Jekyll, no Hugo

After writing pure html, I tested some bloxsom, started writing my own blog templating engine, abandoned that project for Jekyll, and recently learning about Hugo. While Jekyll served me well, its limited feature-set and Hugo’s promise for some relief made me attempt a switch.

Hugo advertises taxonomies, layouts and themes with partials, content with shortcodes, and better templates supporting some simple data-driven documents. Also, “install” with zero dependencies, and speed. While a first look revealed that I more or less had to port everything by hand, it seemed easy enough.

Then reality happened. It includes quirks of my specific site and mind, quirks of technology, and then a selection of concepts that lie between somewhat questionable and maybe wrong.

Sections provide separate feeds and section-indices. Manual action is required to removed those, and manual action is required to combine those across sections. I prefer my current, semi-curated way, with customized index pages (with custom content, not custom layout); fighting Hugo to not do it’s own indexes seems more effort than instructing Jekyll to create a default index page. But that’s probably my status-quo thinking speaking for itself.

A quirk of technology is Hugo’s datetime-handling. Hugo and Go are both underdocumented in that regard, and the interactions between Go’s type system and TOMLs datetime spec result in little surprises even for a programmer. The break from preexisting convention is sane, but results in subtle issues that I’d like to have had a reminder; the prime examples being that all datetimes must be specified either only as date (e.g. 2015-12-31) or down to the second. But whatever. Now I know to use 2016-01-03T15:12:31Z (see, seconds!). One time issue. Mission accomplished.

Another quirk of, uncharitably saying, the “Go mindset” is that many template functions are not designed for piping. Using pipes in templates (like "myvalue" | someFunction with 3 baseArgs | otherFunction) requires that the argument order for functions is specified such that the “work item” argument is the last one. Even stuff like Hugo’s string-replace does not work like that. When writing F# but using C# libraries such issues crop up all the time. Whatever. Just use one more pair of parentheses. Mission accomplished.

Slightly more questionable, though workable, is that a section also declares a default type. Every page you write in Hugo has a type, by default its type is of the same name as the section it resides in, mixing content hierarchy with article type. While I can see this working well for some use cases, it fails the orthogonality test. Hierarchy across several media types is an “off” case needing configuration, and the same layout across several sections requires either repeating partial includes or content type specifications; both trivial but commonplace papercuts. Of course, this just happens to run counter to how I organized my pages.

But whatever. This complicates layout search paths, and causes some repeated one-liners, But it’s a trade-off across use-cases, and my dislike is probably caused by my static-quo thinking repeating itself.

Finally, and this one hurt: There is no use of templates in content files. For me, templates are not just for layout. I intermingle content with some data to create data-driven content, and not data-driven layout. Even though the hugo-homepage declares otherwise, Hugo really only does the latter. Shortcodes are restriced in their environment access, and so for customized indices Hugo fails me, without a workaround.

The last issue was the literal deal-breaker. Most issues might just be artifacts of me using Hugo incorrectly, or could go away as I get familiar with Hugo. While I assume that I can fix this final problem with some more time, it would not be worthwhile for this little site (unlike for a larger project). For now, I hope that this is somebody else’s problem as well and they will fix it for fun, and then I can revisit Hugo with one hurdle less.

Hugo however reminded me of some potential for improving my layout templates. There might some refactoring be in the happening. Sadly, it also reminded me that the default pagination mechanisms are not perfect. (Also, Jekyll can do more than I remembered.)

Summary: I am very bone headed and like my site like it is, and because of that Hugo’s defaults make my life slightly difficult, and break some minor (but important to me) build results. So I decided to keep using Jekyll for the time being, even though Hugo is cool, and will be revisited.