I wrote ages ago (way back in November) about seeing an interesting little templating system called Haml at RailsCamp. Well, curiosity led to experimentation, experimentation led to infatuation, eventually we were living an alternative Haml-oriented lifestyle. Haml has matured quite a bit since then. 1.0 came out in January; 1.5 came out recently (like a month ago) and things are looking quite nice. We had a couple minor hitches due to the shifting sands of active development on a young technology, but that mostly lies now in the long long ago, in the before time. A lot of that is probably due to Haml being a very small, self-contained thing. Which is also why it should take you about twenty minutes to get going with it. There is a nice little tutorial that gets you going from installing the plugin to making your first Haml template.
Here is my greatest hits list of reasons people give for not trying Haml and why you should ignore them.
Reason #1: This is Ruby, not Python! I’m afraid of active whitespace!
Why this makes no sense: Heard of YAML? Which is all over Rails? And is also full of active whitespace? I don’t want/use a programming language with active whitespace, but it makes a lot of sense for certain kinds of data, so get over it. Getting rid of explicitly closing tags immediately got rid of hunting through RHTML for why unmatched tags were wrecking the intended structure of a file. Using indentation to show the structure of HTML documents is awesome and less error prone.
Reason #2: I like syntax highlighting in my editor! Haml is young and saucy, certainly this must not be available!
Why this makes no sense: People who like Haml are super nerds, and have been busily hacking away so that they can use it more pleasantly in their favorite editors. I use the textmate one. There is one for Eclipse/RadRails/Aptana. In progress/useable for Komodo. Vim? Eclipse? Many options are available, more will come.
Reason #3: Learn a whole new language! OMG SO HARD!!
Why this makes no sense: It is not a whole new language. Describing it as a language is almost insulting to the concept of a computer language. It’s markup, it is a combination of elements from CSS, Ruby, and HTML, which assuming you are interested in this to begin with, you are already using. This is so not freaking rocket science, people. It has like 5 concepts. Maybe 4 if flattening gets fully deprecated. Seriously, if you can’t figure this out in less than an hour, turn in your geek badge and maybe take up sorting colored glass or something more your speed.
Reason #4: It can’t do loops! Or multi-line statements! Or some other weird thing I saw while reading email archives from November!
Why this makes no sense: All the block stuff you are familiar with from RHTML files also works in Haml. Your helpers will continue working, the world will continue spinning, people will still find the Rails community vaguely glassy eyed and cultish. Many things have been improved over Haml’s short little lifetime, it’s worth remembering that stuff that was true last December may not be true now.
Reason #5: It might be slow!
Why this makes no sense: Actually, that’s not a bad complaint. Rails in general is slow, ERB is slow, maybe you should worry about this? Of course most people who bring this up just make blind guesses about what probably they think is happening behind the scenes and never bother to benchmark anything. I did and it worried the hell out of me. Haml was > 3x slower than ERB. So I kind of tweaked out about it, started jabbing at the code and optimizing things. Now the development version is only about 1.7x slower, I intend to have it close to about 1 in the near future. I did a proof of concept getting rid of prettification of the HTML output that runs about 2x faster than ERB. So: speed is coming, there is nothing about the Haml concept that makes it intrinsically slow. Also: open source means getting to investigate, identify and fix your own damn problems. Let this be a lesson to you.
(Another lesson to you is that you should try Erubis. Pure ruby, 3x faster than ERB, works great with Rails. To those who think application performance is always bound by db and never by view rendering, you are wrong and you should not generalize your case to everyone. Railsbench is your friend and you may be surprised by how much snappier you can make things.)
Reason #6: But in such and such specific case, RHTML is better/easier to read!
Why this makes no sense: Actually, this is completely true. I noticed just today that I prefered to use RHTML for some email templates I was making. They have no CSS related structure, they just drop a couple names into a big blob of email text. So I just used RHTML. Haml is appropriate for things in which CSS and structure of the document interact heavily. If this isn’t the case, don’t use it. Mixing and matching is awesome. RHTML and Haml are both painfully simple. If you can handle walking and chewing gum at the same time you should have no problem using them both.
Well, this post… ended up much, much snarkier than I originally intended. I’ve seen a number of odes to the joy of using Haml recently and so I took the opposite tack of lining up the main objections I’ve seen knocking around and taking them (at least partially) down. Share and enjoy!