Rebuilding My Blog in Jekyll Again

I just finished rebuilding this blog in Jekyll for the second time. After ten years of using WordPress for a variety of sites, I made the switch to Jekyll in 2021. For my first Jekyll site, I used one of the many free Jekyll themes with some customization. This time, I built the site mostly from scratch.

There was definitely a learning curve with Jekyll but a couple of things made me want to move away from WordPress in 2021. For one, I felt like I had reached the end of my journey with the whole LAMP stack. Aside from building the occasional WordPress site, I wasn’t really doing much PHP development. I had taught myself PHP and MySQL in 2007 in order to build my own microsites and landing pages but didn’t really start using WordPress until around 2012.

From 2012-2016, I had been mostly focusing on learning Python and Django along with a little bit of blog development in WordPress and PHP. In 2016, I made the switch to Ruby and Ruby on Rails and had finally found a language and a framework that made development fun.

Since I wasn’t regularly building sites in WordPress, every time I needed to build a new content site it just felt like I had to do so much setup work and relearn where everything was among all the different files. Having to set up a local instance of Apache and MySQL, even with packages like MAMP and XAMPP, and then boot everything up every time I wanted to work on the site was getting a bit tedious.

WordPress is a fantastic platform with a huge ecosystem of themes, plugins and developers. Since its inception in 2003, it has had a huge influence on the evolution of publishing on the web. By some estimates, WordPress currently powers over 40% of all sites on the web.

However, WordPress’s popularity is a large part of its problems. The platform has had numerous security issues over the years. In particular, the WordPress plugin ecosystem, which is part of what makes it such a great platform since there are plugins for just about anything a website would ever need, is the main source of security vulnerabilities. As a matter of fact, there is a product called WPScan that is entirely devoted to finding vulnerabilities in WordPress sites.

While I have seen some fast WordPress sites, my (and many other people’s) experience of it was that it is a bit slow to load at times. There are a lot of optimizations that can be done to WordPress to speed it up and make it more secure, but the fact remains that keeping WordPress secure and fast requires a lot of extra work than simply setting up a website and publishing content.

All in all, I (along with many others) feel that WordPress adds an awful lot of complexity when most people just need a simple way to publish content on a one-person website. For large websites where there are a lot of people of varying technical abilities regularly publishing posts, WordPress has a lot of extra features that can make it worthwhile. But for me, I wanted to try something new.

Static Site Generators

Over the past several years before making the switch from WordPress to Jekyll, I had been noticing that several sites I had seen using Jekyll and other static site generators were blazingly fast to load and incredibly responsive.

Since I already had been using Ruby and Jekyll is built in Ruby, it seemed like the logical platform to start with. Jekyll, which was created by GitHub co-founder Tom Preston-Werner in 2008, is widely considered to be the first static site generator.

There are quite a large number of static site generators these days. The ones that I seem to hear about the most are Gatsby (written in React), Hugo (written in Go) and Jekyll. At VMware (where I most recently worked), I was responsible for compliance for hundreds of microsites that were outside of our main site. These sites were built in a number of different platforms, some of which were static site generators. Several of our open source sites were built in Hugo with one or two in Jekyll.

Probably the biggest difference between a platform like WordPress and a static site generator is that static sites don’t use a database. This alone eliminates a lot of headaches and a large number of security and speed issues. In Jekyll, there are layouts which are basically templates that contain all of the page’s design elements in HTML and CSS. The layouts also contain variables written in Liquid that are template placeholders for content. Content is placed in separate Markdown files which get rendered in the layout templates when the site is built at runtime. The local development server is easily started and stopped via the command line. Sites can then be deployed (for free I might add) from your machine and then hosted on GitHub Pages or Netlify right from a GitHub repo.

Learning to use a static site generator does take some time. You do need the ability to read and write HTML, CSS, some JavaScript and, in Jekyll’s case, some Ruby as well. Liquid and Markdown are also necessary and take some time to feel comfortable. If you’re at all like me, in the beginning the process will be painful and the learning curve steep. However, once you get the hang of how static sites fit together, it really makes development much simpler and actually quite fun.