Choosing a static site generator for the blog

I had considered writing a blog for some time, but was not sure what to write about, or if anyone would find my content interesting. After speaking with a friend, I decided to just go-ahead and do it. As I am a software developer, most of the topics are probably going to be about writing software, likely with a focus on .NET back-end development as that is what I spend most of my time doing. I constantly work on my own side-projects in addition to my day job. This helps me to learn new technologies and play with them in ways that I cannot during normal working hours. Doing this has forced me to figure out many issues for myself, so I will likely be writing a bit about how I went about solving these problems – hopefully, somebody else can learn from me and save themselves some time. 

This first blog post will not be about software development. After deciding to write a blog, I had to figure out how the blog was going to be hosted. I have heard of Static Site Generators recently (SSG’s) becoming a popular method of hosting a blog, instead of using a blogging platform based off a Content Management System (CMS) such as WordPress. I am already quite comfortable with WordPress administration as a I manage a few websites using it. Still, as SSG’s were becoming more common, I thought I should investigate if using one instead of WordPress would be a good idea. 

First, I had to figure out what a SSG was – at least compared to WordPress. WordPress is a complete web application written in PHP backed by a SQL database. It supports user-accounts, user-sessions, commenting and has plugins which can extend the platform with features such as analytics and caching. WordPress stores its data within the database and then dynamically creates webpages based on requests and what data is in the database. On the contrary, a SSG is a tool that takes content written in some format (often Markdown) and then turns it into a bunch of HTML files that can be directly served over the Internet. While WordPress is arguably more powerful, even loading a simple web page requires the application to fetch data from the database, process it into the webpage and then return this webpage to the client browser. A statically generated website just returns the HTML that has already been generated.  

One issue I found with SSG’s is that as the website is generated before being uploaded to the webserver, this generation must be done somewhere – either on your own machine or via some online build tool such as GitHub Actions. As a developer, this would not be a problem for me to set up, but I wanted my blog to be something that I could sign into from anywhere, write to and post my articles, and be done. I did not want to go through a development workflow to post something new. 

There are also many SSG’s to choose from – likely because they are not too complicated to develop and so make for fun side-projects for developers to work on. My research led me to three that seemed interesting – GatsbyHugu and Statiq. I was leaning towards Statiq as a .NET developer. They all seemed remarkably similar to each other, with some being a bit more mature than others. In essence you need to configure your theme and other configuration settings, write your article in the mark-up format required and then run a script to generate the HTML. There are various SSG-specific plugins you can use to extend the functionality of the SSG. The content can then be uploaded to a host and a Content-Delivery Network (CDN) can be used to speed up loading of the site. 

So yes, Static Site Generators do seem like the cool-new-kid-on-the-block, and the developer-minded workflow works well for me as a software developer. However, I still felt like WordPress is a better option for a blog. It may be a bit bulkier, but with the correct setup it can be optimised to run relatively fast. The excellent plugin support also allows me to extend the website if I choose to do so and there are a massive number of plugins available. Also, I can do things like create a user account for an editor who can check my writing and make the necessary edits without having to run the SSG tools to rebuild the website. I can also post-date articles so that they only go live some-time in the future. There are also many high-quality themes available for WordPress. SSG’s are improving in this area, but I found that there is still much more choice on the WordPress front. 

In the end I decided to stick with WordPress. It was fun playing with the various SSG tools available, but as I already am comfortable with WordPress and know how to maintain a WordPress installation, I stuck with it. WordPress is still under active development and when set up correctly, it can run fast enough to keep up with a SSG site. In addition, it provides me with a proper user authentication system and has plugins that I can use to extend the website. Maybe I will move over to a SSG in the future once they have further matured, but for now I feel WordPress is the better option. I am investigating using SSGs for software documentation though – I believe they may be a good fit for that use case. 

This post ended up being a bit longer than I expected it to be. I hope you found it interesting and thanks for taking the time to read it. 

Leave a comment

Your email address will not be published.