So, here we are, a fresh new Hugo blog, using a ported version of the old Twenty Twelve theme for WordPress. The look and feel has been perserved as much as I could, together with most of the original contents.
The Sins of WordPress
WordPress, being the de facto choice of CMS1, is as versatile as your imagination goes. Its flexibility allows you to build everything that is a collection of pages and articles, with the help of some plugins. I love the flexibility of WordPress. I used to make a living writing plugins for WordPress.
But being feature complete comes with a lot of drawbacks. Just to name a few:
- Require a decent server to run
- Require a MySQL database (the maintenance of which is painful)
- Require frequent upgrading and maintenance just to keep secure
- Bad performance
- The (not so useful) complexity of the editor
All these problems add up to around 10USD/month of expense, 2 man-hours of maintenance labor, plus the risk of data loss and being hacked anytime, only to run a small blog which virtually nobody cames to read, except for some spiders.
At some point last year, I decided all this is too much and decided to make the change.
Cloud Immortality Basics
Cloud has been the buzz word for the whole software engineering industry of the last decade. While used everywhere, it really only means “other people’s computer”. But there are some differences between using your own computer and other people’s computer, the biggest one being the deprivation of states.
Your computer is your computer. It implies the fact that you always possess and are able to use that one computer, until something really bad happens. This gives you the illusion of being able to store everything on it with only minimal mathematical expectation of losing your data. But this assumption is, in fact, very fragile. We call this paradigm stateful.
Other people’s computers are different. You borrow one of them with some API call, and you are billed by the “resource usage”. This comes with a implication that you can’t always get the one computer, since when you release it, other customers might borrow it. So you can’t store anything on the computer now. However, most software you run will still need some storage for its data, so we had something else specialized to store these data (the state), and make the computer stateless.
Maintaining stateless software is relatively easy. It can be designed to be killed anytime2, and multiple instances can be spawned or recycled automatically3. Life and death (or as people used to say, the “lifecycle” of a process) is now meanless. By being stateless, you become effectively immortal. This is the only goodness the cloud brings to this old industry.
The Journey to Cloud Immortality
Hugo the Static Site Generator
Hugo is not a good static site generator. Fast is its only virtue. It comes with incomplete documentation, implied features, and filename-based configuration, just like every other software written in Golang. But it is fast. And has some support for multilingual sites, like this one.
It takes me about 40 man-hours to port a simple WordPress theme to Hugo. Data migration took far more time, even with the help of semi-auto migration software.
Porting the Theme
Porting a theme to another CMS is somewhat easier than writing one from scratch. The WordPress official themes provide very nice accessibility features for screen readers and browsers without JavaScript enabled, so you don’t really need to consider these features much during porting. Static files can be simply copied over, while PHP files require rewrite under the not-so-elegent template engine.
Editing Experience Revisited
WordPress classic editor (TinyMCE) is heavy, generates unnecessary HTML tags, and loads slowly. I always found myself using the raw HTML editor to remove excessive tags it generated with no actual use. The block-based new editor (Gutenberg) looks less tech-savvy, but I disliked the whole idea.
Markdown based editors are a lot better. They make the most common options much easier, and gives you (imaginary) full control when you really need to. I really like this kind of experience. Plus, GitHub Copilot is a great tool to help you with this. (Copilot wrote the last sentence. Really.)
Deployment on the Cloud
GitHub Pages
GitHub Pages has been around forever. It only support Jekyll sites or pure HTML sites, so you have to generate the sites manully, then push the files to another repository, which I feel unnecessarily complex.
Netlify
Netlify comes with decent build machines and support for most static site generators. Their build images are based on Ubuntu LTS, comes with NO root access (2500:2500 with no sudo), and you can install software by Homebrew. The configuration is easy too.
There is one drawback though: There are no way to reference “the latest build image”, so every 5-10 years, when a Ubuntu LTS image is out of support, all your sites stop building and you have to fix them one by one.
Cloudflare Pages
Cloudflare Pages tried really hard to mimic Netlify’s build environment (image, environment variables, and a superset of pre-installed software) and configuration (compatible _redirects and _headers), so I had to write more code to make my build script compatible with it. Their build images are Ubuntu based too, with NO root access (2500:65534 with broken sudo, so it is harder to install anything on it).
Vercel
Vercel’s build enrovinment is based on Amazon Linux 2, which is just plain old. It comes with Hugo 0.58 (also very old) by default. The only good thing about it is that the build image runs by default as root, so it is a lot easier working around things. I don’t like it very much, though my build script tries to be compatible with it.
Self-host
There is actually an option to self-host the static site, and it is much easier to maintain compared to a full WordPress installation plus a database. And you don’t need to backup the site, only the source files.