May 29, 2015
5 min read

Migrated to Jekyll

I just recently moved the blog over to jekyll as the Jekyll team got into releasing beta versions of its 3.0 release.

Despite it’s popularity in the Rails community for a while now (enough so it raised eyebrows at me having a roll-my-own blog system), up until 3.0 I had issues with Jekyll , but the new version seems to eliminate most of my larger bugbears.

Strangely, the big catalyst behind the move was themes (and an interesting point of how policy can drive behaviour), as Google announcing it was going to start punishing sites that were not mobile responsive in its search results had organic traffic (and my search rankings) drop by half the week google pulled the trigger on it. Redesigning my theme from scratch to be mobile responsive seemed a lot more work than modifying someone else’s theme. But, while that probably clinched it, there were other good reasons too:

  1. Generation time dropped As a static site generator, particularly for my large site, it took a long time whenever I used jekyll to generate my blog. Ridonkulously long in the old versions (my blog has been going for over 10 years and has 2000+ posts. The new jekyll seems a magnitude faster and with its incremental generation means I’m getting sub-minute generation even on large global changes.

  2. Github Pages is nice I have to admit, the git push origin master for Github pages and automatic hosting and being able to have your own domain for GHP makes it a really nice, easy way to deal with your blogging (even compared to the rake deploy task I have in Kobayashi.). Just fire and forget is nice (and if there is an issue GHP mails you a nice email telling you the build failed.).

  3. Lots of nice themes to modify Probably the main thing that grabbed me &emdash; a lot of the themes are lightweight, well-designed typographically, and most importantly, mobile response, which saved me a whack of work in redesigning the site. Modification is so much easier than from scratch, especially if you’re weak on creating designs.

  4. Constantly improving code base While I really loved building Kobayashi, it’s a surprising amount of work even supporting a small project with updates. While Kobayashi’s code base is just under 250 LOC, there are actually 75 gems (even though only 16 are specified) that go into making it so lightweight, and updates on these would sometimes introduce breaking or strange changes. I began to think it might just be better to simply contribute to jekyll.

Strangely though, after a month, I’m still only slightly better than on the fence about the change as there are still a number of things that Kobayashi does better:

  1. Tag indexes and urls A surprising thing for me was the fact that while Jekyll claims to support tags natively, it doesn’t, even in the 3.x branches have a core method for creating tag pages automatically. This seems like a silly oversight, especially since most people simply want a tag index page and a page for each tag you can link to which lists all the posts tagged with that result. While there are plugins that will do this, they’re not supported on Github Pages (which, for me, is the one overriding reason to use Jekyll).

  2. Future posts handled automatically Since Jekyll is static, well… it has no concept of past and present. Strangely, you can have it not generate future posts, but this is something you’d think would be a no-brainer. Of course people only want future posts to show up after the date on which they should. A bit strange this isn’t support, though perhaps when you think about the fact it’s just a static site generator, makes a bit more sense.

  3. Liquid as a template language is still meh While it does what it needs to, and its quite easy to code, Liquid still feels like one more thing to deal with compared to just writing templates in straight up haml or ruby if you are already a developer (and let’s face it, both jekyll and kobayashi are targeted to people with at least basic coding skills.). Still, you can get up and running on it quickly enough.

  4. Kobayashi’s codebase is small and easily understandable Jekyll has been broken into bunches of different gems, which makes things trickier to understand, I find. I really like the fact there is a teensy code base that drives kobayashi and keeps it very understandable.

So, while I’m quite happy with the change and grateful for the team that has done all the great work on jekyll, and the community of designers who have done some nice, modern themes, I still have to say I wish I had the time and inclination to build momentum around Kobayashi. I’m a little sad to sunset the software, but ultimately, if I’m philosophical about it, the fate of all apps is largely one of being superceded eventually.

The one big thing this also pointed out from my side was the fact that I really need to spend some time upgrading my front-end design and coding. The other possible solution here was that I could have rolled my own theme (and before Google forced the issue, a re-design of with a 99Designs type kickoff had been a goal.). Need to level up those skills.

In any case, I’ll extract out the latest updates from the my blog and roll those into the Kobayashi code base on github shortly to release it as open source mostly just for archival reasons.