Half-baked blogs

There’s been a lot of blog chatter recently (beginning, it seems, with Brent Simmons’ “A Plea for Baked Weblogs”) about so-called “baked” blogs. The concept is simple: in a time when CPU cycles are cheap and bandwidth is seemingly limitless, why do so many bloggers use dynamic blogging frameworks that crumble when traffic spikes? Instead of relying on full-stack, database-backed web applications, why not just generate static files whenever content changes and upload to any run-of-the-mill web server?

There are strong arguments to be made for this “baked” approach. The performance of static files just can’t be beat: Apache was hosting static files long before WordPress was a twinkle in Matt Mullenweg’s eye. When you host static files, you can forget all about that time you spend looking for the MySQL password you made up three years ago, or trying to remember which WordPress cache plugin you’re supposed to use this week. Baking your blog gives you access to all of your content in plain text – and you don’t need to worry about TumblBeasts eating your hard drives.

But there are tradeoffs. (Marco Arment and Dan Benjamin cover many of the isses on Episode 18 of Build and Analyze.) Configuring software to bake your blog takes a fair amount of technological proficiency: not problem for most web developers, but a serious obstacle for average bloggers. Worse, using client-side software means that you’re now tethered to a computer – good luck posting from a mobile device. (Yes, you could follow Marco’s example and build your own Dropbox-backed baked blogging system, but then you’re stuck with yet another service to depend on.)

In short: baked blogs make sense if you are technically proficient, plan to write posts on a computer (not a mobile device), and already have a place to host host static files.

After thinking through these tradeoffs, I settled on a solution for this blog that’s become more and more popular.

To generate the static HTML for my blog, I’m using Jekyll, an easy-to-use, command-line Ruby application. Getting it set up was super straightforward. I first created a liquid template for each page type, along with all the usual CSS. Each blog post and static page is a Markdown file with some extra metadata at the top. To generate the site, I run jekyll on the command line (Protip: jekyll --server --auto is a great way to test and preview your posts and designs).

The final piece of the puzzle is GitHub Pages, which makes it incredibly easy to update and deploy a static site. I’m storing this blog in a repository on GitHub, and every time I push, GitHub automatically builds the site with Jekyll and hosts it for free. Thanks, guys!

All in all, I think I ended up with a pretty slick solution – from a developer’s perspective, at least.