Hugo

When I originally learned about Hugo, I thought … what a brillant idea. And then I learned that for years I had missed out on a fully branch of web-technologies. I had my head stuck so deep in things like CMS, PHP, frameworks and dynamic web development, that I had forgotten about the simple things. Let us go back to the roots …

“There are literally hundreds of static website generators.”
Statement found in some o’Reilly-Book about static website generators.

Static Website Generators

The problem with dynamic web development is basically its volatility: exploits and patches come in and you have to take care of these. Be honest with yourself: it is somewhere between hard and impossible to manage a handful of websites to a professional degree. Even auto-update mechanisms as offered by some CMS or some providers will eventually create a mess to be sorted.

There is a way out … avoid all dynamic elements … stay static … use plain HTML. Ok … I can hear you … “HTML?”. You are right, let us stick with Markdown. Markdown is easy to write and easy to read.

So all we need is a framework to bring together:

our Markdown
the site’s theme
some Javascript and CSS

This is what a static website generator does: it implements such a framework, typically supported by a template-language.

So … here is the killer-feature: a static website is free of maintenance. Unless a new browser-generation with new HTML, CSS or Javascript comes up, there is no need to touch a deployed site. So you will never find ads for blue pills, penis-enlargement or other embarassements on your site, which is cool. So this technology has the lowest possible security-risc-level.

Hugo is a static website generator written in Google’s Go. The template language is … logically Go-templates.

Hugo is pretty cool:

write your content in Markdown or HTML
organize your content right to your own needs
use a ready-to-use theme or create or customize your own

Hugo provides an internal server that will give you a perfect development experience: the server pimps your pages with a reload code, so whenever you save a file, Hugo will reprocess the pages impacted by that file and the page will automatically reload in your browser to reflect the changes.

Honestly, I think that Hugo is nice by way from optimal. I strongly believe, that something written in TCL or XoTCL would allow for so much more. Simply because the template-engine being the complete TCL-language is by dimensions more powerful than the go-templates. I was about to plan such a development, when I came accross the citation at the top of the page. There are more the 400 SWGs and I did not want to write another one to drown in the masses.

SCM/GIT

One sexy aspect of Hugo or SWGs in general is that everything is just code, plus a few images or media files. Usually all of this can be handled in a git-repository. You will never lose any content from your website again. And if you get your website destroyed, impacted, hacked, whatever, you rebuild it - ideally - with a single command.

Deployment, for tests

Hugo has been picked up by some companies like netlify. Netlify offers a free plan for personal projects, hobby-sites or experiments. The service is pretty complete:

integration to your favorite GIT hoster, like Github or Bitbucket
continuos deployment … your push your repo and the services builds and deploys your site
HTTPS is available
you can use your own domain-name, all you need to do is configure the nameserver at your domain-hoster
global CDN deployments

Netlify is not the only competitor in the market, there exist quite a couple of them. Kindly search and evaluate that to find the best offer that suites you!

To say it straight: this is the easiest way from an idea to a presentable website. There is a downside, though: I got no information about privacy, so traffic on your site might be followed by trackers and such annoyances. Some services might even inject ads.

Deployment, professionally

Professionally, you want to use your favourite webspace-provider and your own account. So your webite-provider will cover the web-space needed and the HTTPS-certificate (usually via let’s-encrypt).

So how to deploy to your server. I see two options:

deploy manually, typically using a script, nothing to say against this. You may resort to shell-scripting or an SCM like Ansible.
CI/CD … I love Jenkins. I used a VM that I run on some hoster, installed and configured Jenkins via Docker. Runs like a charm. Whenever I push my repo to my GIT hoster, Jenkins pull it and builds and deploys the site. This is great.

So my workflow is simple: I check my changes using the hugo-server and once I am happy with the result, I push it and wait for the changes to reflect on my site. This typically takes a minute. Cool!

For more complex changes, you might resort to git-branches.

That one big downside: comments

A well-known blogger, Jeff Atwood, once stated “a blog without comments is not a blog”. There is some truth to this. So, how do we get comments working? At this point you must decide what you have:

an own personal site with a few comments per month
a full-fledged blog with dozens, even hundreds of comments per day

For case one: do not look further. Just add an id in the frontmatter and add some code to the footer of your theme, to allow sending comments by email. Do not use a contact-form, though, unless you have HTTPS. It is slightly safer to just use a mailto link. Your template may prepare the subject to contain the id of the article. Thus prepared, you mail-client will help you with spam-filtering and you may write a little script to copy and paste the email. In the end the script will insert the comment before something like a comment-marking HTML-comment and allow editing that file. A shortcode may help you to format the comment, properly.

For case two: use a service like disqus.com, just with a better privacy-support. This is possible, but basically not for free. Then again, you do earn money with your blog, don’t you?

A nice review of options for comments can be found here!

Conclusion

Unless you need interactive features, like comments, application-features or alike, an SWG is a good options to be considered.

Pretty often it might even replace a full-fleged CMS: GIT would be able to provide workflows based on branches and pull-requests and such. This would allow for small to medium teams.

Also the possibility to work straight in the theming alles for more flexible use of Javascript and CSS.

My own use of this

I have an internet-VM, where I keep my sources, so I can edit them even from my mobile-phone.

My GIT repos are managed on Bitbucket, allowing for private projects.

A second internet-VM runs a Jenkins-server (ok, I could have done this on one), once I have all this setup coded in Ansible, I will like bring Jenkins over to the first server.

I am about to implement comments: mail-based. So the theme will add a mailto-link if the frontmatter contains a related identifier. This way, under each page a comment-link optionally appears, including the related privacy-links and -explanations. I create a separate email-account named comments@mysite.whatever and expect the ID in line one. A script will take a copy&paste version of the mail-body and scan the id and a username from it. The user-synonym will be used whereever the email would be and add a shortcode to the related article. For this it will scan the frontmatters of any content to find the related article. This mechanism is replicatable with little to no effort and can be operated from my mobile-phone, if I so want. In order to limit SPAM, I might use a frequently changing, cryptic email-address and/or an API-key in the subject. This way a simple mail-filter will eliminate any fraudulent attempts. Furthermore, the email-address might be constructed using a few lines of javascript, thus a robot will access the wrong email-address.

You will find your own solution, I like this hacky one.