Hosting my new blog with Hugo
Tags: hugo, blog, rpi, wordpress
Published: 2020-05-13 04:49:27

In the last few days I've decided it's time to start [my own blog](https://manse.cloud), so here we are!  This blog is intended to contain a mix of topics such as programming/technology, philosophy, and other random thoughts, with an emphasis in that order (primarily technology).  In making this decision, I found myself asking the question, "Do I really want to use Wordpress?".  For my work, I run a small but growing software development company, where we focus mostly on integrating systems and creating internal tools (usually in the form of web-apps).  I have a good understanding of the lifecycle of not just running CMS's like Wordpress, but also how to create them.  And so the question is: do I go for the simple solution of setting up WordPress, or do I give in to temptation and minimise my chances of success by over-engineer a solution for this brand new project?

In the end, I've decided on a compromise: a static site generator.  I won't be taking the easy path of using WordPress, but I also won't be doing something enormously difficult.  A static site generator lets you create your content and then build the raw html files based on templates and content you provide it.  If you then edit a page, or add new content, you rebuild the site and upload a new version.  There's no fancy JavaScript behind the scenes (though you could add that if you wanted), just the plain old html files.

There's a few reasons why a static site generator appeals to me over a full CMS platform like WordPress:

* Fast!  Since we're just serving raw html files, once the site is deployed there's no processing for the server to do beyond reading the file off the filesystem and sending it back to the client.  Furthermore, if we keep our templates clean, these files can be very small.  With some generators, no JavaScript is required for rendering the site.  Unlike a React site, we aren't providing the equivalent of an application for download, just the final rendered HTML.  Furthermore, given that the content is all static, such sites are very friendly for hiding behind a CDN like Cloudflare, and can be served very fast around the world with ease.
* Ease of deploy.  To run this system, all we need is a server capable of serving up static files.  That means I could throw this site onto a Raspberry Pi behind a [Caddy](https://caddyserver.com/) server instance (caddy), throw them into a [Google Cloud Bucket](https://cloud.google.com/storage/docs/hosting-static-website), or any other simple hosting mechanism I like.  There's no database required.  A static site opens up hosting opportunities unavailable to sites like WordPress.
* Low system resources.  I plan to run this on my own Raspberry Pi 4, a relatively beastly machine.  With plain HTML files, no server side rendering, this thing is super easy to host on a low cost machine like the RPi.
* Security.  Since there are no moving parts, your security risks are much more limited to things like the server you're running it on, and the service that serves the files (Caddy, Apache, etc).  It significantly reduces the surface area for possible attacks.
* Control.  There's a great simplicity to running a site like this, and with that simplicity comes control.  While I can modify the internals of WordPress, there's a great deal to learn to do so in a competent way in line with the way WordPress has been designed.  With straight HTML templates, it's much simpler for me to make changes and understand the consequences.  Of course, with WordPress comes the *significant* advantage that there are a ton of plugins pre-made to do what you want, so I don't want to oversell the case here -- but there is an appeal to the control that comes from simplicity.
* Markdown.  Out of the box, many static site generators let me write content in a simple way using Markdown, which I'm keen on.

There's no question that a static site generator involves more fiddling than paying a nominal hosting fee, choosing a template, and starting your blogging WordPress.  However, the reasons above on balance have weighed in favour of me going the static file path.

And for that task, I'll be beginning this journey with [Hugo](https://gohugo.io).  I did look into fancier JavaScript generators like  Gatsby, but as someone who is not a fan of JavaScript (and excited about the prospects of WebAssembly enabling challenges to its hegemony), and being keen to retain control and simplicity, it's my preference to go with something like Hugo.  Also, while I'm not a boomer myself, I'm old enough to have started learning about web technology when PHP was young, and so [this boomer's sentiments](https://brycewray.com/posts/2019/07/why-staying-with-hugo/) resonated with me (and while I note he has since managed to win his fight with Gatsby, as someone who uses React I lack the same motivation to use something like Gatsby for the purposes of improving my JS/React skills).

# Next steps

With the site up and running, some things I'll be looking at next include:

* Personalise the layout and details (word counts, name, image(s), social media accounts, etc)
* Supporting RSS feeds (which I still use!)
* Cloudflare for caching, particularly of images
* Something for monitoring that avoids Google Analytics, perhaps [GoAccess](https://goaccess.io/)
* Possibly my own dummy JS file so that even if a file is cached by CDN, there's still a hit to my server that I can log
* Newsletter or similar signup option
* [Commenting system](https://gohugo.io/content-management/comments/) that respects privacy (no tracking)
* Tags/categories