Noel Rappin Writes Here

I mentioned on Twitter the other day that I was starting to like using Haml and it was surprising me because I used to dislike it so much. Colin Harris asked me to elaborate, but Twitter was too short, so here goes.

I assume that most people reading this have some idea of what Haml is, if you don’t, it’s an ERb replacement for view depleting which uses Python-style indentation for blocks, and a couple of other tricks for simplifying the amount of markup you need to write in your view – here’s a sample from the Haml tutorial, which gives you the flavor.

#profile
 .left.column
 #date= print\_date
 #address= current\_user.address
 .right.column
 #email= current\_user.email
 #bio= current\_user.bio

I don’t really intend to turn this into its own-mini tutorial, but suffice to say that “=” indicates Ruby execution, and the “.” and “#” allow you to specify CSS selectors, with a div tag being implied, and indentation indicating the extent of the outer tag.

So, how did I go from really hating Haml to mostly liking it? Well, here’s how I came to dislike it.

My first exposure to Haml in use came on a legacy project that I was asked to take over. The project seemed to have been worked on by two people who rarely spoke, as evidenced by, among other things, the fact that the view code was half ERb, half Haml. And the Haml seemed to be tied to some of the ugliest code in the system.

As a longtime Python programmer, I have no problem with using whitespace to mark blocks. In fact, I kind of like it. However, you have to acknowledge that the side-effect of whitespace blocks is to keep your blocks short, and try not to let them get too deep. That’s part of the point – the structure of the code is supposed to guide you to keeping the code concise and well factored. If you don’t pay attention, then the whitespace code – Python or Haml – becomes very hard to follow and maintain.

I’m sure you see where this is going. This first Haml project had long files, with deep nesting. It also, I realize now, wasn’t particularly good at using Haml’s strengths in specifying DOM elements. Every time I needed to touch that code it was a bad experience, and I got very averse to seeing Haml.

I also had a couple of other issues. Among my coding quirks, I tend to be aggressive about keeping line lengths under 80-90, and Haml 2.x didn’t allow you to insert line breaks in executing Ruby code, which led to unavoidably long lines in some cases. (I realize that the point was to keep you from having long Ruby calls, but sometimes, especially in that code base, it was unavoidable.) To a much lesser extent, I was also not attracted to the “If you don’t like Haml you have no poetry in your soul” tone of the Haml website. I’ve come to terms with that, too.

So what happened?

A couple of things. Haml 3.0 made it possible to break lines in Ruby code, and that was enough to get me to look at Haml again. The addition of SCSS over SASS for writing CSS helped a lot – I love SCSS and never really got into the SASS syntax. I started working on projects that used Haml and were smarter about using CSS, making the Haml’s easy creation of complex CSS selectors more attractive. I saw better examples of Haml code that showed it in a better light.

And one day, working on a totally different project that also happened to be half Haml, half ERb, I noticed that the ERb started to fell clunky and heavyweight. The Haml started to feel disturbingly natural.

I started to prefer Haml, using it as the default on new projects.

What do I like about it?

• It’s concise, but after you get used to it, completely readable (again, when written well). It did take me a little while to get used to it.

• Haml makes it much more difficult to write invalid markup, effectively eliminating a source of error

• Haml encourages treating markup like code and writing it in small pieces

• Haml implies the use of SCSS, which is pretty unambiguously awesome.

• As Brian Hogan pointed out on Twitter, Haml makes it easier to restructure the hierarchy of your view output because it’s much easier to change the relative placement of tags.

It’s not perfect. Like all HTML tools that assume an HTML structure, unstructured text is challenging. Ruby blocks still look strange without endings. Other than that, I’m happy making Haml my default view layer. And I’m glad I got over it enough to give it another look