I’ve been constantly making adjustments to my sites ever since I learned Flash in high school. The process typically goes something like this:

I make a site that I’m in love with.

Next day, I hate the site.

I tweak the site some.

I hate the site more.

I make a new site that I’m in love with [rinse, repeat]

It’s a pretty viscous cycle but my latest loop of love/hate felt a bit different from the old days. Instead of falling in and out of love with the design of the site, I’ve begun to fall in and out of love with the site’s back-end technology.

Falling in love with WordPress

When I first begun using WordPress, I was instantly hooked. For years, I had been creating sites by manually creating each HTML page separately. Professionally, I was working with content management systems but the CMS’s we used cost thousands of dollars and hundreds of man hours to create sites new designs with. Even without the huge cost of using them, the systems were at best difficult to use.

Admittedly, I was a little late to the party when I designed my first WordPress site for the show Bring It Home Chicago (the show has gone off-air since) in 2010. Even so, WordPress completely changed my idea of what someone with only front-end coding skills could do.

It was empowering to be able to create dynamic sites and give my clients the ability to update the content on their own, with free software on top of that. WordPress was much easier for my clients to use than any of the traditional paid CMS’s I had used previously.

WordPress Pitfalls

Eventually I decided to use WordPress for my own site. But as the cycle goes, I begun hating it the next day.

The biggest reason I started to hate WordPress was it’s rigidness. Wordpress is extraordinary at creating blog sites with posts and a few simple pages but it gets increasingly difficult as you attempt to change the taxonomy (structure) of the posts.

My original vision for the site was easy to design using WordPress. In fact, I even started building my current site using the tool. But as I started to get into the flow of tweaking the site, WordPress was becoming increasingly more difficult to work with while using my newly developed, Ruby-centric workflows.

Static site generators

While I was looking for alternatives I came across static-site generators. Static-site generators are pretty much exactly what you expect, they generate static files for a website. I know that was a bad definition, I can hear one of my elementary teachers screaming in my ear now.

A better definition is that static-site generators are applications that allow you to assemble websites from separate components into single HTML files.

Think of your typical website’s homepage. It likely has several distinct regions – headers, navigation, modules, etc. Content management systems compile this modules into a single HTML page each time that a user requests the page. (Note: caching makes this statement slightly false but it’s not important for the sake of our discussion.)

Static site generators combine all of the modules into a single HTML file before you push them to a server. Instead of hosting code that compiles the HTML every time a user makes a request the server, the precompiled HTML files are what gets stored on the server.

There are a lot of great reasons to use static HTML when possible. Hosting static files is tremendously easy for servers. This translates into extremely quick load times for your users. While using WordPress for my site, I was seeing load times of .6 - 1.2 seconds for the initial page request. The total time for the full page load sometimes hit 3 seconds. Painful.

After switching over to a static site, my initial page load times decreased to a nearly imperceptible 25 milliseconds. The total page load time is often less than a second!

Falling in love with Jekyll

For me, it was a pretty easy choice to make the switch to Jekyll. Thanks to a class at The Starter League, I learned Ruby and the popular web framework Ruby on Rails. Jekyll happens to be built on top of Ruby.

Jekyll also incorporates many of the tools (Sass, HAML, and Compass) that I love to use when building sites today. Plus you get the added benefit of built-in support for free hosting through Github Pages. Did I mention free hosting?

All of the features of Jekyll are awesome. But it’s biggest benefit was that it allowed me to work in a way that made it easier to tinker with the site. Instead of having to think about existing taxonomies before making my tweaks, I could create new page designs on a whim. Any of the structural issues that held me back were gone.

The inevitable downfall of Jekyll

I know what your thinking, “well if everything was so great, why did you stop using Jekyll?” Like my adoption of WordPress, I was a bit late to the Jekyll party. The GitHub release history suggest that the framework is about 5 years old, I started using it about a year ago.

When the framework was started it was using the latest and greatest technologies to power it. Compass, a powerful library for Sass, was fresh to the party and being rapidly iterated on. Today, competitor Sass frameworks are have more support for CSS3 features.

Tech issues aside, Jekyll just doesn’t support the workflow I’ve come to love and enjoy after learning Ruby on Rails. So I’ve made the switch to Middleman.

Middleman comes packed support for Coffeescript (which makes writing JavaScript enjoyable and fast) and Compass. Although Compass is baked in, Middleman also has robust plugin capabilities that allow you to plugin in other Sass libraries or Ruby Gems much in the way that Ruby on Rails does.

I can’t say that I won’t switch to a different static-site generator in a few years but Middleman is my generator of choice … for now.