Recently, I decided to revive my blog which, like many blogs, had gone defunct for a while. Watching a talk by Scott Hanselman reminded me and helped clarify the reasons for having blog and writing regularly. So I dusted off the backup I had and got to work setting up a new iteration of the blog. This post will be the first in a series to document what was involved in setting up this blog.

Bye Bye WordPress

The previous iteration of this blog was a WordPress site running on servers hosted by BlueHost. WordPress is one of the most used blogging platforms out there (wordpress.com claims it runs 43% of the web) so it was a natural choice. You simply press the buttons to deploy the application, login and start writing! In addition, there are dizzying array of plugins and themes available to handle everything from SEO, caching, CDN management, security and more.

This time around, however, I decided to use a different platform.

WordPress has a few issues that made me reconsider my blogging platform:

• Cost - Since I make exactly zero dollars from my blog, I wanted something that was compatible with one of the free hosting solutions out there. WordPress requires a server to run the PHP-based application as well as a MySQL compatible database to hold the content and settings. I found several options that could run the PHP portion of the stack, but the database became the sticking point.

• Performance - WordPress is also notoriously slow. Do search for “wordpress slow” and you’ll see page upon page of sites with tips and tricks to make it faster. While each version gets progressively better, it still requires a lot of work to make it perform well. For the previous version of this blog, I had to install a number of caching related plugins to avoid many of the calls to the database and serve up what is, essentially, static content.

• Security - Given the popularity of WordPress, it gets a lot of attention from hackers. I can’t tell you how many requests I received on the previous version of the blog from bots looking for well known vulnerabilities in older versions of WordPress. Updating security settings, installing plugins for MFA, and the like required a fair amount of work to make sure the blog remained secure.

• Maintenance - Keeping the application and all the associated plugins and themes up to date with the most recent security patches and fixes took a fair amount of time. I have a day job, so I wanted something that required minimal maintenance. Since WordPress has no native version control built in, I also had to do regular backups. There are automated solutions, but remember, I’m looking for low cost here, and many required a paid subscription.

Static Generation for the Win

All this led to the decision to use a statically generated website. With a static website, there is no server to host, just a set of HTML, JavaScript, and CSS files sitting on disk. A blog doesn’t really change much, even for a prolific blogger. When a new post is published, you simply regenerate the site and and upload it to your hosting platform.

So how does a static website fix the issues from the WordPress version of the blog?

• Cost - There are many hosting providers that have a free option for static sites. After all, it’s just a set of files to serve up, no real processing necessary. You can get by with pretty low-powered machines or share resources with other websites.

• Performance - A static site is super-fast. There are no database calls to make and no server side logic to execute. We just serve up the HTML and related JS/CSS files. The only thing to worry about is the size of images, and the JS/CSS bundles.

• Security - Since there’s no database, the threat to a static website is much lower than on a WordPress site. If a hacker does manage to get in and deface your website, you just delete everything and regenerate the site from source. The main thing you have to secure is your source code. If you use a service like GitHub, it’s security is much better than anything I could cobble together.

• Maintenance - There is very little maintenance required for a static website. Any patches or updates to the framework happen locally, within the confines of a source control system. And if I do mess up something, I can always revert to a previous version of the website and regenerate. The whole thing lives in source control, which is the backup system, meaning one less thing for me to keep up with.

The Choice

As it turns out, there are several frameworks available to generate static websites. There’s even a plugin for WordPress that will do the job!

So, how to choose?

I had an idea of what problem I was solving, so I put together a list of candidates and evaluated each one. While, I didn’t put together a formal matrix, as mentioned in a previous blog post, I did think about a few criteria for each one:

• DasBlog - Written in .NET Core, which isn’t a technology I’m super-familiar with. It also seemed a bit heavyweight for what I was looking for.
• GetPelican - Python based, which I’m familiar with. Supports themes and plugins, though it was harder to peruse what they actually looked like.
• Jekyll - Ruby based, which I’ve never worked with. I’m all for learning something new, but maybe not all the things all at once!
• Hexo - Javascript/Node.js static site generation. Rich set of themes and plugins, and a language that I was familiar with.
• WP2Static - WordPress static site generator maintained by Strattic. Reading the docs, it sounded fussy to get working. Plus I didn’t really want to keep a WordPress site running locally in Docker just for the purpose of generating a static site.

All of these options appeared to be actively updated and maintained, though the themes provided by the community were in various states of maintenance.

What did I choose? (drum roll please)

Going with my gut, Hexo is the framework I chose. It seemed simple to use, is based on a technology I was familiar with, and had a reasonable set of themes to get started with.

To be honest, I probably would have been happy with several of the options. But sometimes you just have to avoid the analysis paralysis and just make a decision. Rarely are you locked into tech choice…there’s usually a migration path if things don’g work out.

My main goal was to get a site up and running that I could start writing content. Using Hexo seems like a reasonable way to do that for the time being.

In part 2, I’ll walk through the process of getting it all set up.