I’m jumping on the bandwagon. My vague ambitions to start a blog have combined with my desire to build something outside of Drupal (the technology that has been at the center of my job for six years). So like The state of Hawaii, the federal government and Drupal developers Jeff Eaton, and Matt Farina I’ve turned to Jekyll.
From the Jekyll docs page:
Jekyll is a simple, blog-aware, static site generator. It takes a template directory containing raw text files in various formats, runs it through Markdown (or Textile) and Liquid converters, and spits out a complete, ready-to-publish static website suitable for serving with your favorite web server.
That’s a lot of jargon that boils to two principles that appeal to me.
1. Only think about something when you have to think about.
For a webpage like this one to get to a browser it is necessary for a computer to stitch together these words along with some template code and stylesheets. Jekyll does that work as I write and save a post. Drupal and most other modern site-building tools will do that work over and over again as more people ask for the webpage. The “over and over again” approach allows a site to be slightly different for each logged-in user or to constantly update something like the “most popular stories” list. Losing the ability to “think” every time a page is requested feels like I’ve thrown out the majority of my toolbox as a web developer. And that’s ok. For a site this simple it’s not necessary to carry around those heavy tools to constantly rebuild a site that’s not actually changing very often.
2. Version controlling content
Jekyll keeps the contents of blog posts in text files (Markdown in most cases, mine included). That means the same tool (Almost certainly git) used for managing changes to the code of the web site can be used for tracking changes to the content. And the tools for managing code have become wonderful in the past few years. Clay Shirky’s TED talk on git is the best explanation I’ve seen of why git is worth noticing. For one thing, controlling content through git means that a person can fix a typo in someone else’s blog as easily as they’d correct a bug in open source code. Managing content with git will produce other unexpected modes of collaborating and I’m exciting to have a blog that can be a part of this shift.