Initial thoughts on Hugo over Wordpress
Initial thoughts on Hugo vs Wordpress
The move to Hugo from Wordpress was a long time coming but also a little impulsive. I’d used Wordpress for a long time and had become accustomed to its pros and cons. It’s too soon to talk confidently and about good or bad bits, so here are just some observations.
Also, it’s worth pointing out this quote that sits on the official Hugo forums which neatly encaptures the intended users of Hugo:
Some Knowledge Required
Dare we say that while Hugo is indeed pretty magical, it is not meant to be a “magic wand” to suddenly give you a published website a la Square Space or Wordpress. You are expected to already know how to assemble a static web page, for which you do need some basic knowledge of html, css, command line and text editors. Or how to prepare a space to host your website. The bottom line is, if you are unwilling to invest the time required to learn these things, then Hugo is not for you.
It’s fair to say that I do know how to assemble a website but I have not yet invested the time to fully learn the Hugo way… so I’m expecting my take on the below to change over time.
Hugo is really really really fast to compile / render your content
It’s right there on the Hugo homepage - talking a lot about how fast Hugo is. And it is true - it is blazing fast to render the output. But this isn’t a particular feature to me - the site renders in just a couple of seconds - but so what? Now that everything is installed and mostly running, then my only real requirements are to publish new articles from time to time and so the ability to render the full site in just a few seconds doesn’t really mean a lot.
BUT one real benefit here is the LiveReload feature built in to Hugo - this works really well and makes live editing and tweaking very interactive.
One new article touches a lot of files
Static websites works by pre-rendering all the output ahead of time - including the various linking and index pages. With a dynamic language and a database, displaying e.g., all articles in a certain category can be done at runtime on demand. To have this functionality in a static website, the page showing the same list needs to be rendered and then uploaded to the webserver. The same is true of tags and any other quasi-dynamic pages you wanted. So a new article in a couple of categories and a few tags can result in many, many updated pages - all of which need uploading to the server. Your choices then are to either figure out what changed and just upload that - or, just upload the whole lot every -single- time.
And obviously if you wanted to change anything that impacts the layout / style or other shared item, this can mean the whole site needing to be redeployed.
Publishing new articles is more involved than just saving
THe Hugo CLI tool has built-in tools for deploying content - if you use one of the supported cloud services of which the big ones are supported - if you want to use them. My understanding is that with one of these services, then Hugo will track what has changed and will do incremental / delta deploys - I’ve not tried it yet so I’m not sure.
I use a ’traditional’ webhost which for the mostpart means SFTP for transferring to the server. And unfortunately due to a single new article resulting in a lot of resources being re-output; and the fact that to support SEO friendly URL structures means actual output folders (as opposed to clever web server tricks) means it is slow to upload.
Authoring in markdown is a different experience
There are a number of considerations here. Whilst all tools support drafts and publishing, with a tool like Wordpress you don’t need to worry too much about where you are if you want to add new or edit content. Whereas with Hugo, if you start an article in one place and want to finish it somewhere else, then you do need a means to centrally store the files… a cloud service or online repo is the obvious choice; provided it gives you a mean to sync.
And to be clearer, the benefit of using a source control repo is that this can then hook in to a deployment mechanism; so with a commit to e.g., your master branch, you can then do one (ish) click deployments of the new content.
Writing in markdown will take some getting used to. The benefit of an online tool is that it can simplify the process - whether that’s for markup/formatting but also for making linking to other content (internal pages) or uploading and embedding media / images. Writing in markdown in an editor gives you none of that. I don’t mind the simplicity of just having a few markdown tags to use. And using something like Visual Studio Code - which has built-in support for live rendering markdown. The same functionality - preview mode I suppose - in Wordpress was painfully slow. And of course there is no dependency on an internet connection.
Other missing interactions
The plugin model in Wordpress has a bunch of security vulnerabilities - that’s a given, no question; but that aside, it did offer some interesting additional features. The key things I’m missing at the moment are:
- Search
- Publish to social media
My Wordpress site for example would automatically Tweet about new posts; and it was also possible to have an embedded view of my own Twitter timeline there on the site. I am sure this is possible, but early investigations indicate they require integration that is considerably far more complicated than doing it with a CMS-style framework. (But then you mostly accept this when you move to a system like Hugo.)
Other minor oddities
This blog talks occasionally about tech built using the .NET framework. However, you can’t use that as a tag in a UNIX-like environment - anything starting with a . is treated as hidden and therefore breaks. I used this sit to rattle through the now published site to find and fix broken links.
Next steps
Those are the major observations for now and in hindsight they look fairly negative. In retrospect, for all the issues, Wordpress did make publishing life very simple. Will endeavour to come back in a few months and update this.
In the meantime, I need to get deployments working properly (possibly with rsync) and if that’s not possible then I will likely have to start looking at other webhosting services, such as render, which have better built-in support for deploying content.