The Old Ways: Migrating the blog to Hugo, and a brief personal history of web development

General
The Old Ways: Migrating the blog to Hugo, and a brief personal history of web development
Page content

A few days ago, using time off from work following the back-to-back hurricanes we endured here in Florida, I decided to bite the bullet and migrate my site off WordPress. And strangely, the tool I chose – Hugo – is both a throwback to an earlier time and also the cutting edge of web development. Like any good paradox, this requires some explanation.

The WYSIWYG Age

At risk of alienating any younger readers: how many of you remember Adobe Dreamweaver?

If you wanted to build web page in the late 1990s, but didn’t yet know HTML, you had to rely on WYSIWYG (what you see is what you get) editors. They functioned much like a word processor: you enter text, format it, add image and links, and save it as a .html file. Dreamweaver was the most popular WYSIWYG HTML editor, but there were many others.

I first started building web pages around 2000. In fact, I didn’t have access to Dreamweaver; instead I used AOLpress. It was free software from AOL, with the same core features as Dreamweaver, though not as many bells and whistles. One feature I appreciated was a link mapper that could verify that your hard-coded links pointed to either internal pages or external web sites.

After a while, I started looking at the code generated by AOLpress. The editor would leave a lot of tag artifacts (such as </h1><h1> within a header element), and I realized that I could hand-code the output to clean it up. After some experimentation, I was able to ditch AOLpress and hand-code all my web pages.

My old Tripod-hosted page, taken from a Wayback Machine snapshot.

My old Tripod-hosted page, taken from a Wayback Machine snapshot.

Since I couldn’t afford a paid hosting service, I used Tripod.com’s free service. Without the modern convenience of (S)FTP, I relied on their web interface to upload files, one at a time, to their server. I also filled in my self-taught gaps with their extensive Code Monkey tutorials.

(Their hosting service also injected ugly banner ads into anything it thought could be an HTML page – and ad blockers weren’t as prevalent back then!)

From Building to Programming

But this was all very light on actual programming. Other than learning how to use server-side include files and a couple Javascript snippets for mouse hover effects, I was just building straight HTML.

The only programming language that Tripod exposed was Perl, and I didn’t have a need to learn Perl. I stuck to writing some very teenage blog posts, which I called “articles” as there was no concept of a “blog” just yet.

Eventually, I transferred to a small college in Swannanoa, NC called Warren Wilson. A work crew supervisor there noticed I had put HTML in my list of skills, and he quickly scooped me up to work with the web crew. I was responsible for helping faculty and students with creating web pages, and had time to learn PHP and CSS on the side.

This two-year experience was the basis for what ended up being my profession (or at least my day job) as a web developer/integration specialist/application support analyst.

Why Reinvent the Wheel?

However, while building web sites for a living eight hours a day, I found that my desire to build and maintain code for my personal sites had shrunk.

In 2011, I was starting to get serious about writing as a hobby or even a career, so I started this blog, then titled Full of Fried Fish. At the time, there was one very obvious choice for blogging software: WordPress. It ran on PHP+MySQL+Apache, the most common web technology stack even today, and you could either write content entirely in the WYSIWYG editor or switch to a code view to hand-tweak whatever you needed.

And there was the increasing importance of cyber security. PHP is an easily exploitable language (partly due to its ubiquity), so why create a custom framework that will eventually be cracked, when you could use a well-maintained CMS that gets issued security updates regularly from real professionals?

My output has slowed over the years, and I changed the name of the blog to Too Much Recursion (I still get occasional jabs about “Full of Fried Fish”). But I had no impetus to move off WordPress. Despite a growing marketplace for other CMS frameworks – including ones that are static site generators, which I’ll get to later – WordPress was still “good enough” and did its job just fine.

Too Much Pressure in the Tires

Earlier this year, I realized that I don’t use most of the features WordPress is known for.

  • I turned off commenting years ago, as the spam and occasional hate mail just isn’t worth the limited engagement it offers.
  • I was the sole author on the site.
  • I had no need for custom post types beyond just “blog posts.”
  • I posted in a limited fashion, sometimes going months between updates.

Sure, WordPress was probably overkill at this point, and a slimmer CMS with my needs in mind could do the job better, but there was still the issue of migration. At first, it didn’t seem worth the effort.

But through conversations with developers, I couldn’t help but see how difficult WordPress was getting to manage. I don’t just mean the core software, although the Gutenberg project to migrate to a blocks-based editor didn’t help performance one bit, but also the ecosystem of plugins.

If you’re not familiar with WordPress development, imagine the disdain you might have for that overbearing in-law who won’t stop talking about crypto at Thanksgiving. WordPress developers feel the same way about plugins.

To get anything beyond the core functionality of WordPress (which is really just adding posts, moderating comments, and tweaking site styles), you need to install plugins, often one or more for each feature you want. Plugins also conflict with each other on occasion, and they may require subscription plans to work, and those plans may increase in price year-over-year.

I had heard about WordPress instances with over two or three dozen plugins, some of which had interlocking dependencies, and having to pay for way too many CPU cycles and megabytes of RAM to get even decent performance. The tricks used in the industry to speed up sites, like using a CDN to cache pages and serve static assets, weren’t helping as much.

Now, this didn’t affect my site, as I ran a slim install with little traffic. And perhaps this wouldn’t have been enough to get me moving. Until the Automattic drama arrived.

Founder Mode

To this day, I barely grasp the nuances behind the beef between Automattic (the organization which developed the WordPress framework) and WP Engine (a hosting solution with automated WordPress installs). Automattic insists that WP Engine is infringing on the WordPress trademark by using “WP” in its name. I don’t think this argument holds much water, as there’s precedent in the open source community for companies and organizations to re-use a product’s name if it’s been repackaged (like all the Linux distros do).

I suspect the real beef is that WordPress.com (a separate entity from WordPress.org, where the WordPress CMS is maintained), which is a one-stop hosting shop affiliated with Automattic, is a direct competitor to WP Engine.

So Matt Mullenweg, the founder of Automattic and the one who made the original fork of WordPress from its progenitor b2/cafelog, appears to be running in founder mode, a terrible “management style” that can lead to micromanagement and burnout. Besides writing a series of bizarre, passive-aggressive posts to WordPress.org’s newsletter, Matt has sicced his legal services on WP Engine. Automattic even forked a plugin created by WP Engine and, due to how WordPress sites are set up, issued a security release to force sites to download the new version that Automattic now controls. WP Engine counter-sued, and this will drag on for years.

At some point in all this, I decided that WordPress couldn’t be trusted any longer. Do you blame me?

Pack the Moving Van

So, time to move out of WordPress town. So why did I choose Hugo? Here’s a technical rundown.

  • Hugo is a static site generator (SSG). Unlike a standard CMS like WordPress (and others like SquareSpace, Ghost, etc.), a SSG builds a site using static files, i.e. running no server-side code (like PHP, Python, etc.). It’s all HTML, CSS, JavaScript, and whatever images or other media files you want.
  • The site content is generated from Markdown files. It’s a text-based format with simple markup, easy-to-read markup, e.g. using _foobar_ to italicize foobar. You don’t need to close tags like in HTML, it’s far simpler than LaTeX, and you can use any text editor to write in it. If you ever read text files in DOS or Linux, it should feel familiar.
  • Sites built with SSGs tend to be much slimmer than those built with WordPress and other CMSs.
  • Hugo, like other SSGs, can be integrated into any production environment. This is what I mean when I say that it’s both ancient and modern: it’s ancient because it just spits out static HTML files, but modern because it integrates with Continuous Integration (CI) tools. You run the SSG locally, it generates the files you want, and you can put them on virtually any server at all, or even a data store like AWS S3. (Or you can do what I do, and just SFTP the files to a server using rsync)
  • Unlike other SSGs, Hugo is self-contained. Most other SSGs are built on node.js, which can lead to issues with dependency management (and I deal with that enough at work). Hugo is written in Go and has no runtime dependencies after compilation.

The biggest benefit of using an SSG, in my opinion, is that the attack surface is near zero (apart from the server you run it on). There’s no PHP scripts running on the server to worry about, no possibility of SQL injection. As I mentioned, it’s all static HTML files.

But there are downsides:

  • It’s a fair bit of setup, which is offputting to non-technical users. If any of the jargon above got you lost, this isn’t the product for you.
  • Migration was a chore. I used a good tool by lonekorean for turning a WordPress export.xml file into a directory of Markdown files, but it required a lot of finesse to get it to play nice with Hugo. Even after all that, I still needed to manually tweak a lot of older articles.
  • You either need to build the files on your own computer or set up a Continuous Integration (CI) pipeline. Unlike WordPress, you can’t just post from your mobile phone unless you have a github repo, have it linked to a CI pipeline, don’t mind typing code on your phone…
  • It doesn’t have the same level of support as WordPress. If you break your Hugo site build, be prepared to dig around on the web or tinker a while to find a solution.

Are the Old Ways Best?

Using Hugo really does feel like I have one foot in my days as a budding HTML coder creating lean websites, and one in the present day with repos, CI pipelines, and so on.

However, I feel this is a solution only for those like me: technically savvy writers.

Interestingly, there are some developers who use ancient WYSIWYG HTML tools to build their websites; the code those produced was bloated for their time, but nothing like the megabytes of Javascript and CSS that websites load nowadays.

What about regular users? If you’re looking for some alternatives to WordPress that don’t involve using the command line, this post by Ernie Smith lists many alternatives, and who they would be most useful to. There are alternatives, but each comes with its own disadvantages. After all, WordPress’s enormous user base and ubiquity is hard to ignore.

But maybe the old ways are calling to you. You could even create your own webpage from scratch, just using HTML, and find a hosting provider for your hand-crafted markup. You might even get a career out of it. I know I did.