Static websites are great. Hugo is a really great static website generator. Except for a few things (some not even Hugo’s fault!).
Why static websites are great
Static websites are those that consist of nothing but a collection of, you guessed it, static files of any kind (text, images, etc..) sitting on a Web server. You write all your web pages as a collection of good, old plain text files. A single program, that is the website generator, automatically converts them in static web pages, with embedded images, working links and menus, RSS feed… that are then automatically copied on the web server where everybody can read them. Static websites do not work in many scenarios, but are just great in many others. In a nutshell, static websites are great because:
- they are much less vulnerable to attacks, because they do not require any other software but the bare Web server to be accessible from the Internet
- for the same reason, they load fast even from slow servers, or through slow connections
- all your content remains in a format that is always, immediately reusable in many other scenarios, and basically guaranteed to be readable even decades from now
Hugo!!!
In the last few years, my static website generator of choice has been Hugo. This blog, my main one, my few ramblings about backpacking or everything else, as well as my main home page are all made with Hugo. Have a look at them to see how diverse Hugo-generated websites can be, and give Hugo a try.
This said, there are a couple of things about Hugo that I really, really miss.
Standard formats and syntax for themes and configuration
To really see both how flexible Hugo is, please visit the official gallery of Hugo themes, and then have a look at this thread, which is just the last real-world example of what bugs me the most in Hugo.
In “traditional” Content Management Systems like WordPress, if you switch from one graphic theme to any other one that was declared as compatible for your WordPress version, the website may become ugly and miss a few widget, but it will still work. In Hugo, instead, changing from one theme to the other can mean things like:
- your home page goes almost totally blank
- ditto for “partials” (= Hugo name for page building blocks like footer or header), see here for details, and all that whole thread
- icons or links to one’s social media accounts are not generated, because not all themes identify them with the same tag
- images are not inserted because certain themes recognize the IMG tag, others don’t
- more work to define post thumbnails in home page: with some themes, you can define this image with the “image:” tag in the frontmatter, with others you must use “thumbnail:” to achieve the same effect
The last two issues are particularly bad because they mean one should change the source code of all the posts of a blog when switching themes, instead of just adding (possibly redundant) settings in the general configuration file. NOT good.
Now, I know perfectly that this is all software (and unpaid time!) freely shared, that nobody is in a position to actually force others to comply to any guideline and so on. NO question about that. Take this whole paragraph as constructive confirmation that common (naming) standards for tags, shortcodes, partials… are really useful. The only change I do strongly suggest to the Hugo developers is this:
please ONLY list, at themes.gohugo.io, themes that are actually interchangeable and fully working by changing as little as possible (besides the actual “theme” setting, of course), and only in the general configuration file.
The themes that, for whatever reason, require messing with Markdown source files, or the structure of home pages, or renaming partials etc… should really be listed in a separate page.
A comment system with the SAME philosophy and features of Hugo
Even if it is a static website generator, Hugo can already support reader comments by embedding in its pages both external services like Disqus, and self-hosted ones like hashover. Now, Hugo is and must remain a static website generator, so what follows is not a request to Hugo developers. But let me say that what is missing, in my opinion, is a comment system for Hugo that is just like Hugo, that is:
- 100% self-hosted
- 100% portable when migrating to another hosting provider (ideally, it should not be a separate server, but “standard” PHP code that even cheap hosting accounts can support)
- blocking spam with captchas, not user logins
- like Hugo… 100% static, when comments are closed
The last bullet point means that the ideal commenting system for Hugo may be something like:
- something like hashover, packaged in a way that it is as easy as possible to install
- a standard “COMMENTSCLOSEDAFTER” setting in the Hugo configuration file
- a standard shortcode saying “COMMENTSHERE” for all Hugo themes
- an external script that for each post, after COMMENTSCLOSEDAFTER days, automatically converts all the comments it received to one chunk of HTML or Markdown file per post, with a standard naming convention
- Hugo replacing the COMMENTSHERE shortcode with the hashover code, or with the “chunk” above, depending on how many days passed since the post was published
I could write the script in n. 4, but not the code in points 1 and 5. If anybody is interested, let’s discuss it.