Why I Decided To Use Jekyll

For too long I have procrastinated creating a personal hub for my writing. Well technically, I do have a working website built using Wordpress, but in my opinion, the authoring experience is dreadful, and as a result I have not posted a single piece of content in nearly two years. The WSYWIG editor, while offering large control over formatting, produces sloppy HTML that doesn’t quite sit right with my OCD. The requirement of internet access, or in its place, a local installation of Wordpress, is another layer of complexity that I find unnecessary for the simple task of publishing my thoughts.

This blog post is in no way constructed with the intent to bash Wordpress. Wordpress is an impressive tool. It brings to the table an easy installation process, support from all major hosting vendors, a vast library of plugins, and a thriving community. I can however confidently say, it is not the right tool for this particular job. I have very basic needs. I need a place to write and share my thoughts, nothing more. As Markdown is a very natural format for writing structured content, I began my quest by narrowing down various blogging platforms that natively supported it.

Investigating Ghost

As a front-end engineer, I hold javascript near and dear to my heart. It was the first programming language I had the opportunity to work with, and even with all of it quarks and oddities, I still find it an expressive language to work with. Ghost, as you may have read about on Hacker News, or seen on Kickstarter, is a node based blogging platform, created by former Deputy Head of the WordPress UI Group, John O'Nolan. It boasts a beautiful dashboard, and an elegant web interface for authoring. At first glance, it appeared to be a very promising tool and a good fit for my requirements.

I prepared a cup of coffee, cleared my desk, and began on my journey to javascript nirvana. With excitement, I began researching, first by reading user reviews, and eventually making my way to the official documentation. Hosting appeared to be small obstacle, but one I felt more than comfortable taking on. I was already the proud owner of a VPS running a few node processes managed by upstart/monit. In my mind I was only a few dependencies shy of having a working Ghost installation. Why would I investigate any more options? I had the chance to be one of the cool kids using the newest toy on the market. Naturally, I moved onto setting up a local installation.

The documentation pointed to a Vagrantfile created by the Ghost team. Vagrant was a tool I used daily at work, and learning that it was the recommended method for creating Ghost's development environment, only made me more confident in my choice. If you do not have experience with Vagrant, I highly recommend that you take a look.

$ git clone git@github.com:TryGhost/Ghost-Vagrant.git
$ vagrant provision
$ vagrant ssh
$ cd code/Ghost
$ npm install
$ grunt init
$ npm start

Easy right? Unfortunately, no. This post would be written in different light had it been so. Running Mavericks OSX with the latest version of both Vagrant and VBox installed, I was unable correctly provision a working environment. I would resolve one complication only to see another arise. It began with issues regarding Vbox Manage; next was Guest Box Additions; and finally npm module permissions. I had sacrificed close to two and half hours, before making the decision to move on. The complexity of managing Ghost, both locally and in production, proved to be more complex than I was willing to deal with.

Static Site Generators

I was well aware of static site generators prior to my endeavor with Ghost. I even knew that the majority of static site generators on the market would meet my needs. What can I say? I wanted to play with the newest and shiniest toy. I wanted to brag about how great an experience Ghost offered to my coworkers, who continually ragged on javascript. Pride damaged, I reviewed several well known static site generators, to see which would best adhere to my requirements. There were several options built using node, including but not limited to, Docpad, Assemble, & Wintersmith. Each had a certain appeal, but at the end of the day, a poor ecosystem of existing templates, and the lack of available time I had to learn a new system, drove me to use Jekyll.

Jekyll

My familiarity with the platform, comes from hosting documentation for several of the opensource libraries I maintain. Due to integration with Github, Jekyll has gained widespread developer adoption. This benefits not only the template ecosystem, but also the tooling around the product. As an example, Prose.io is an opensource web content editor for Github. It provides solid integration with Jekyll, and a result, I have a functioning mobile interface to edit and write content.

After searching for a viable template, I was only left with the following.

$ git clone git@github.com:rosario/kasper.git
$ cd casper
$ gem install jekyll
$ jekyll serve --watch

A few css tweaks later, and I have a blog I am happy to call my own.


Special thanks to rosario for porting over the default Ghost theme Casper.