This blog currently runs on Movable Type, and has since I started it back in 2003 on version 2.65 (dang, my first post is quite a snoozer). I even wrote some plugins for version 2 and 3 to cope with some of the limitations of its permalinks.

However, I recently learned that version 5 will only supports MySQL. This is a huge disappointment as SQLite is one of the major reasons I chose Movable Type (see my comments about upgrading to MT 4). I don’t know what’s motivating this decision, but it really makes no sense. Is it really that hard to write database neutral SQL? Surely this is a solved problem by now.

This is so bad that it’s deal killer for me, and I’m starting to investigate my options going forward.

Why Not Movable Type 4

The simplest option is to just keep running version 4. Obviously, it works for me, and it’s the choice with the least amount of effort. But MT4 isn’t perfect, either.

The big issue is it’s templating system. I blame the templating system on why my blog looks like ass and doesn’t match the rest of the site.

Maybe I’m just an idiot, but the whole theming system hurts my brain. First off, the entire theme is stored inside the blog engine. In order to edit the templates, you have to edit them inside the browser. This is incredibly lame.

You can link individual templates to a file on the file system, but you have to manually do this for each and every template. In MT4, there’s something like 20 different templates, and I’m not about to go through each and every one linking them to a file. (Have I mentioned I’m lazy?)

I think you can use a plugin as a theme, but the documentation on that has been very poor. There’s no “simplest possible theme” plugin that you can use as a starting polint and build up as necessary. You’ve got to somehow extract an existing theme into a plugin, which of course, there’s no easy way to do, last I looked into it.

What am I Looking For?

Here’s my must-have list of requirements for a blogging system:

  • Generates static pages.
  • Does not require a client-server RDBMS.
  • Support writing posts in Markdown or Textile.
  • Simple, yet flexible templating system based on files on the file system.


Basically, this falls under the KISS principle. My posts and theme almost never change. There’s no reason to eat up CPU and memory generating a page each and every time someone hits it. The big downside to static is that it generally means no comments. Services like Disqus, though, mean I can add comments even to a statically generated blog.

Static also means fast it’s fast. I don’t need to install the latest and greatest super-duper-OMGWTFBBQ cache plugin. And getting Fireballed won’t take down my site. The few times my site has been linked by more popular sites, my server hasn’t so much as strained itself, let alone failed to serve up pages.

No Client-Server RDBMS

I don’t understand why so many blog systems require a full-blown RDBMS like MySQL or Postgres. Don’t get me wrong, I love Postgres, but it’s overkill for 99% of the blogs out there, including mine. An RDBMS complicates setup. It complicates backup. It’s one more thing I have to keep secure. It’s, somewhat ironically, a hinderence to scalability (*cough* “Cannot access MySQL” errors *cough*). There’s a lot of overlap here between static generation, but they’re mutually exclusive as Movable Type itself shows.

If you’re writing a blog engine and you really feel the need to use SQL, for all that is good and holy, use SQLite or at least allow it as an option. SQLite will more than scale for most blogs. The database should be almost entirely read-only. Even if you support comments, I doubt you are getting comments added in the hundreds per second category, which means, SQLite will be able to handle your load.

Many static site generators forgo a database completely and just use the file system. You edit the posts by editing ordinary files. Plus, it means I can check the whole thing into version control, too. This is very tempting and seems like it’s even better than SQLite.


I’m a geek. I don’t need no stickin’ GUI editor for my posts. Heck, I could even write them in plain HTML, but Markdown does make things like paragraphs, emphasis, lists a little simpler. I’m also lazy, so making things simpler is a win.


I covered this a bit above in my current dislike for Movable Type 4, but I want a templating system I can edit completely in the file system. This way I can edit them with a real text editor, and I can store them in version control. Having stuff like this in version control is so awesome because it gives you a safety net for mistakes.

Other Considerations

I love MarsEdit for posting. I’ve been using it ever since it was part of NetNewsWire. However, none of the static blogging systems have a remote API like this. I’m perfectly capable of just editing Markdown files, but there’s something to be said for a dedicated blog editing app. In my ideal world, I could post either by adding a file or through MarsEdit, whichever strikes my fancy.

Current Contenders

Unfortunately, static generation and SQLite support rules out the most common blog systems like Wordpress. However, I’ve already got a few contenders in mind. They’re all Ruby-based static generation systems, namely:

I’ve already got a good idea of the pros and cons of each. My shortlist is Rote, nanoc, or something custom. I need to evaluate each a bit more, though, to really find the winner. Or maybe I’ll just be lazy and stick with MT4.