Some time after writing my last post about switching this blog to Jekyll instead of WordPress, I got an interesting comment from a reader. When I published my reply, it became so long that I thought it would be suitable for its own blog post, this one. Below is the part of the comment I replied to, and a revised version of my reply that is more suitable as a blog post.

“…this ‘Jekyll’ you speak of, are you sure switching over to it was a good move? Not that I’m trying to make you second-guess yourself or anything. It’s just that I’ve never even heard of it and from what it sounds like, it sounds similar to Plume and DotNetNuke and the like… Platforms, all of which, get hairy to deal with. Besides, wouldn’t sticking with Wordpress be better in terms of universality and modularization of not only code but also, end-user facilities?”

Comments are always appreciated! It’s also great to have some people over from SitePoint, which is where this reader came from. It’s a fantastic community for anyone in the web industry that I’m trying to contribute to and be at as often as possible.

I’m not second-guessing any of my recent decisions. First of all I believe I made the right choices, second of all, second-guessing is not productive, and third, it’s my own blog so I can switch it back and forth at any time.

As for why I switched and why it’s a good move:

Curiosity was one of the main reasons why I switched to Jekyll. I saw the SitePoint article about Jekyll and it made me interested. I quickly checked out the options mentioned above and if I’m correct, they are CMSs. Jekyll is not a CMS, and that fact is the reason why I found it interesting in the first place—it’s a lean tool for generating a static HTML site from a set of templates, pages and posts. Kind of like “compiling” a site.

In my case I definitely think it’s suitable and I also wanted to learn how to use and deploy it for future reference. Since I’m a developer and always wrote my posts as markup even in WordPress, I feel that the supposedly better end-user facilities mentioned in the comment are just slowing me (and the site) down. I don’t need them.

As for universality and modularization—again, since I’m a developer I’d rather use Jekyll to write my own customizations quickly in Ruby exactly as I want them, or re-use open-source code, than go looking for plugins with configuration pages and other extra features I don’t need. Since the end result of Jekyll is a static HTML/CSS/JS site without constantly interpreting PHP or Ruby on the server side, and without the need for a database server, the site becomes leaner, faster and can be deployed pretty much anywhere.

I’d love to try this out again on a client project. Hopefully it’s a matter of time before a project shows up which it’s suitable for. Since there is no CMS/back-end/control panel built into Jekyll, the client would have to know how to use a markup language such as HTML, Markup or Textile. No biggie. But it should also preferably be a small to medium sized site, since it needs to be re-generated when there’s a change or when new content is added.

A great aspect of using Jekyll with Capistrano as the deployment tool (and Git as source code management/version control) is that you’ve got full control over the automated deployment process—that’s another big reason why I wanted to use it. Running "cap deploy" in my OSX Terminal from the site folder will re-generate the site (with any new content) from the code and posts in the Git repository on my server, and move it to my production environment. To make it even simpler, I suppose I could also set up the Git repo with hooks that re-generate the site automatically whenever a new post has been committed.

This might be tough for a client if he’s not so tech savvy but I’m thinking there are several ways to make it simpler. For example, by either having a cron-job on the server that runs every once in a while to check for content changes, or create a quick control panel just for allowing the client to re-generate the site whenever he/she wants. Doing the latter would be a great project, and perhaps it could also feature a small reference and help section for Textile/Markup syntax.

I believe many clients would really appreciate the simplicity of such a solution as opposed to using a larger and fancier platform such as WordPress or Drupal, despite the good-looking WordPress admin panel. For many clients, a full CMS is just “too many buttons and features”—it slows them down and confuses them.

Of course, the first concern should always be the site requirements, and many times a CMS solution is preferred. Sometimes it’s even a requirement from the client (“we want a WordPress site”). But I definitely believe that a tool like Jekyll can be a great solution in some cases—especially if you go out of your way to further simplify and automate things. I’d really love to try it out on a client project soon because I’m confident I can make the client love it.

Again, thanks for the comment—it’s always a pleasure!

Leave a comment or share this on Twitter.