Haml 1.7 (and 2.0)

Haml 1.7 has been officially released!

This is very exciting. There are tons of cool features and a really awesome speed boost, but those are all covered in the release notes. I want to talk about what this means for Haml development.

The next Haml release is going to be version 2.0. As such, we’ve skipped over version 1.8 and made the current development version 1.9¹. Because it’s going to be a full-version release, we want to make it a really impressive piece of software.

For v1.0, we were striving for stability, in the sense that the code would perform consistently and without bugs. For v2.0, we’re going for a different sort of stability: we want to stabilize the feature set. After 2.0, we’re pretty much not going to add anything to what Haml can do, or deprecate anything that it’s doing. Maybe if a feature is clearly needed we’ll add it, or if something is totally redundant or never used we’ll cut it. But it’ll have to be something really big.

We also want to focus on increasing quality of the codebase. Although I think we’ve managed to keep it pretty nice and modular so far (if I do say so myself), it’s definitely not what it could be. Code is duplicated, there are tons of random class variable flags, all sorts of nasty things like that.

So we plan to do more or less a complete rewrite, at least of the core. “But wait!” you say. “Joel says you should never rewrite software!” Well, okay, Anonymous Objector. We aren’t actually going to chuck it and rewrite it from scratch. Joel’s right; that’s stupid, for a company or for a project like Haml.

What we are going to do is take the current codebase and incrementally improve it, in the way that the Agile folk love to advocate. Find something ugly, make it beautiful, make sure all the tests pass, repeat. The idea is that this will eventually involve everything ugly being made beautiful, thus resulting in a beautiful codebase more or less completely different than the original. Or it could just end up with a differently ugly codebase. Only time will tell.

We also want to focus on performance. Haml being 1.8 times as slow as ERB is pretty good², but we can do better. Tom Bagby, whom if you’ll recall made the awesome performance improvements from v1.5 to v1.7, accomplished most of that performance stuff by rendering the HTML tags and attributes that didn’t contain dynamic Ruby content before the Ruby stuff needed to run. If we store this in a clever way, we think we can get rid of a lot of what’s still slowing Haml down.

If all goes according to plan, 2.0 is going to be even cooler than 1.7. Look forward to it!

¹ We’re going for a Ruby- and Gnome-style versioning schema, alternating minor version numbers between development versions and released versions.

² A bit of trivia: according to some benchmarks Hampton ran, Haml’s 18 times faster than Markaby, the other popular alternate rendering engine.