Jekyll makes blogging fun again
Jekyll describes itself as a “blog-aware, static site generator in Ruby”. It is written by Tom Preston-Werner, the co-founder of GitHub. You may have already seen that this very weblog is powered by Jekyll. An article discussing the pros and cons of this emerging technology seemed like a suitable first post.
You may wish to begin by reading his account of the creation and rationalization of Jekyll. Tom’s article also goes into details about how to actually create a Jekyll site. The GitHub repository is also well-documented, and he provides a useful example site repository, so I will not go into implementation details here.
As of this writing, Jekyll is in version 0.4.0.
All about Jekyll
Instead of blogging on a remote Web application, Jekyll enables you to personally store your blog’s template and all its content. Blog posts are Textile files. The site itself is just is a series of HTML templates that are transformed by the Liquid templating engine.
Why this is important
Once you apply Jekyll, your site becomes a directory of plain-text files that now may be trivially placed into your favorite version control system (VCS), such as Subversion or Git. This enables you to track changes to your posts, store an offsite backup, and access it from any remote computer with a VCS client.
In addition, your blog becomes immune to high traffic to which regular blogging sites fall victim. Database-powered blogs that lack caching are traditionally slow and susceptible to grinding to a traffic halt when the Digg hordes come running. If you’re a popular/controversial blogger (I am neither), or you’re hosting a site on your own small server, then static pages are definitely the way to go.
When it all comes down to it, having complete control over your blog and having its contents in a non-proprietary format gives you piece of mind that you just can’t get from a blog Web application.
Other cool features
You can run Jekyll with the --auto option to automatically rebuild the output files whenever a source file changes. Combine this with the --server option and you have a dynamically-updating Web server on which to preview your award-winning blog.
Also note that Jekyll will transform any file that has a special YAML header at the top, and this includes XML files. This very site has an Atom feed which I pulled directly from Tom’s site.
I was dreading learning the syntax and idiosyncrasies of the new technologies upon which Jekyll is based. My fears were confirmed in Liquid (more on this later), but Textile has been a joy to use. It’s no LaTeX, but notation is compact and it feels easy to write. However, it will be a while before I stop typing “textile reference” into Google.
You might miss some things
Jekyll has lots of other features I’m not using here: each post can have categories and tags. These are derived from the directory structure in which the post file is stored. This metadata can be accessed and filtered using Liquid. You can even provide links to related posts.
What you don’t get is all the dynamic goodness of a bigger blogging app. Most notably, you lose the ability for visitors to leave comments. This works well for a personal, broadcast-style blog, but if interactivity is a must, then you should seek a more dynamic blogging solution.
Commenting can be achieved through third-party comment solutions, but it’s not as well-integrated, and you lose almost all customization. This blog uses Disqus.
Quirks and downsides
You’ll have to learn Liquid and Textile. Knowledge of Ruby helps, too. Hackers such as myself thrive on this sort of thing, but not everyone does.
Liquid
The biggest downfall with Jekyll is its use of the Liquid templating system. Liquid has a very special and limited syntax that doesn’t look or behave anything like Ruby. It’s very protected, making it difficult for users to run compromising code.
Now, Jekyll’s original task was to power GitHub Pages, and Liquid fits this environment well, preventing users of GitHub from running potentially malicious server-side code. However, when you’re running code on your own computer and generating static pages, this just becomes limiting and unnecessary. Jekyll needs to lose Liquid and give us full ERB evaluation, à la Ruby on Rails
Relative paths
Tom was smart to include a --server option that runs a WEBrick server to preview your blog. This is great, but it assumes that your blog or site is going to reside in the root directory of a Web address. The URL generation methods within Jekyll also assume this.
It would be great if URLs were all relative, or Jekyll provided a method to reach the root directory of your blog, e.g. creating the string “../../../” to hop up three directories from a post in “/2009/02/10/” to reach a stylesheet at the site root.
Summary
Jekyll is fun to use. It’s a solid, simple, and useful project that brings blogging full-circle and molds modern Web writing styles with the static HTML coding days of yore. It gives you full control and access to your site, at a minimal cost of time, money (static HTML hosting is free or cheap), and server resources.
If you’re an enterprising hacker, or just someone who wants to keep a simple, no-frills, leisurely-updated personal blog, Jekyll is the ticket.
In the future, I intend to try to address some of my concerns with Jekyll by contributing to the project with my fledgling knowledge of Ruby. There’s a still a lot to be done and I’m looking forward to updates from Tom and the team.
Relevant links
Comments
This post belongs to Blogwell, personal weblog of Rockwell Schrock.