Thoughts on Haml
April 29th, 2009
Every so often I get prompted (more or less) for my thoughts on Haml. Someone suggested I write them up.
I’m not a fan. Some vocal number of people are big Haml enthusiasts, and while I think I get what they see as its virtues, it just doesn’t work for me.
In no particular order, here’s what irks me.
I already know HTML. I have no trouble reading it, no trouble writing or editing it. I have an editor, vim, that makes working with HTML fairly simple. I’ve no compelling reason to learn another syntax in order to end up with markup that’s already easy to write. (BTW, if you are not using an editor with auto-tag completion and other HTML/XML helpers you are making a mistake). I get the impression that many Haml fans are programmers who don’t already know (or are not comfortable with) HTML, so they have a learning curve no matter what, and Haml may be less onerous than HTML. Me, I’m not afraid of HTML or XML, and I find Haml Perlishly cryptic.
It seems to grab the worst features of Python and Perl: Magic indentation and write-only syntax. No, I’m not interested in debating the merits of either. I view static indentation as I do most forms of static typing: needlessly restricting in an attempt to solve problems that don’t come up much in Real Life code but make for nice pedantic rants about “But what if?”. I also know that one man’s cryptic is another man’s poetry. Much poetry is an acquired taste, and often bad.
I have a hard time navigating Haml documents. With HTML I can easily jump from the start or end tag of a element to the matching one. This is quite handy when I want to insert something at the end of an element; from the start tag, hit %, and jump to the end tag. Perhaps this is also possible in Haml, but I’ve not figured it out. Instead, in Haml, I do the Dance of Matching Indentation, and sadness follows.
It seems that whenever I see examples of Haml (or Yaml, for that matter), they are pretty short. That’s because the allure of magic indentation wears thin for large docs. (Cute anecdotal tale that preaches to the choir: I made this observation about Python code to a Python fan, and was told that it worked to ensure you kept your methods short. That was the first and only time I was told that the white-space tax had a punitive purpose.)
I can hit some keys in vim and auto-format my HTML docs. I can easily cut and paste chunks of markup and move them around, and have my editor handle the formatting. Not so with Haml, where there is constant risk of offending the gods of The True Indentation.
I often work with Web designers who will send me HTML pages that need to be re-worked into templates. Having to covert that into some other format just so I can get HTML in the end is dopey.
I like HTML over XHTML. See http://hixie.ch/advocacy/xhtml (though the suggestion to use the still “Working Draft” HTML5 is somewhat puzzling).
I’m sure I could do something clever and make sure I send my pages using the application/xhtml+xml MIME type, but I don’t. I don’t see the benefit when I can use HTML 4 and the default Web server configuration. It Just Works FTW.
I used to use XHTML, largely because I could more easily check my Web pages using an XML parser and XPath. But tools such as WWW::Mechanize have become really good at handling HTML 4, so the charm of XML has faded.
Just for gits and shiggles I spied on the headers exchanged when fetching http://haml.hamptoncatlin.com
My browser sends this (indicating that it will accept assorted XHTML-friendly MIME types)
GET / HTTP/1.1
Host: haml.hamptoncatlin.com
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.14) Gecko/20080419 Ubuntu/8.04 (hardy) Firefox/2.0.0.14
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: UTF-8,*
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.google.com/search?q=Haml&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:official&client=firefox-a
Cache-Control: max-age=0
It gets back this:
HTTP/1.x 200 OK
Date: Sun, 22 Mar 2009 01:34:55 GMT
Status: 200 OK
Server: Mongrel 1.1.5
Content-Type: text/html
Content-Length: 4734
... followed by an XHTML file.
I don’t mean to single out the Haml site. This is quite common. If you’re going to go the XHTML path, though, consider doing it in earnest, or it comes off as posturing.
That’s basically it. For those who like Haml, more power to you, just please don’t hand it to me to work with.
If you think I’m wrong on any of my points, please drop me a line with some specific, factual, technical information.
UPDATE:
Thanks to Arthur and Nathan for pointing out that Haml allows for different output types by setting, for example,
Haml::Template.options[:format] = :html4someplace or other.
UPDATE 2:
This is a nice thread on the trouble with Haml Haml doesn’t like javascript
While I appreciate people trying to help me get a grip on Haml, the discussion tends to look like this:
Anti-Haml: It's hard to work withHam'l Qaeda: But look how beautiful it is!Anti-Haml: It imposes superficial constraintsHam'l Qaeda: But look how beautiful it is!Anti-Haml: It gets in the way of doing things I want to doHam'l Qaeda: But look how beautiful it is!Anti-Haml: It makes embedding JavaScript annoyingHam'l Qaeda: Your are a flawed being for desiring that. And look how beautiful it is!:)
13 Responses to “Thoughts on Haml”
Sorry, comments are closed for this article.
April 29th, 2009 at 08:08 PM
I’m very comfortable with html, it couldn’t get any easier so your point of “it’s for noobs” is incorrect for my case and many others.
HTML also rarely changes or has new syntax/elements/attributes, yes HTML5 adds a few but it’s a pretty static markup language.
HAML is a great utility to ease the pain of boring, ugly html code. The difference between an html layout and a haml based layout is amazing and much clearer, even with longer files. It may look cryptic at first but once you get into it, it’s hard to go back. Automatically closing tags and perfect indentation on output are great features to have.
Sass is also wonderful because you can define constants and snippets within your css. For instance you can say that dark grey should be #666 and you can use fixins(snippets) to apply common chunks of css such as clearfixes.
Also the issue you mention with the response headers from haml’s site is just mongrel(the web server), that has nothing do with Haml. Haml is translated server side and in no way effects the response type from the server.
If you do need to convert some html to haml there’s a command line converter html2haml/haml2html, it works very well.
I wouldn’t say that everything needs to be in haml, always having to convert chunks would be a pain, I agree but Haml has saved me quite a bit of boring frontend coding time so that I can focus on the core functionality of my app.
With programming languages there are benefits to coding in it more often, you learn more about the language and how to do things more efficiently. With html there’s pretty much one way to do it and it’s been the same way forever so why waste extra time on it?
April 29th, 2009 at 08:39 PM
While I (mostly) agree about haml, I’m a big fan of sass for the css end of things. I find css incredibly difficult to organize and sass makes it that much easier. This points, I think, to html being less-poorly-designed than css.
That aside, I do take issue with your apparent problems dealing with indentation. It sounds to me like you’ve been able to deal with the obvious problems matching html tags not through its inherent ease, but with technology (vi tag matching) and there’s no reason similar technology for haml (and other indentation-based structures) can’t become available. I wonder if your editor supported such features if you’d feel the same way.
April 29th, 2009 at 08:44 PM
“The difference between an html layout and a haml based layout is amazing and much clearer, even with longer files. It may look cryptic at first but once you get into it, it’s hard to go back. Automatically closing tags and perfect indentation on output are great features to have.”
Thanks for posting, but this is exactly the sort of comment I find useless, yet hear all the time from Haml fans.
Even after explaining that I’ve used Haml, do not care for it, do not care for how it looks, find it unpleasant to deal with, find it especially troublesome with large file, I’m told to ignore my own experience because Haml is beautiful and clean and a great utility.
That’s why I asked for specific, factual, technical information.
“It’s beautiful, you just need to give it time,” is the Hamlist mantra. It’s annoying because it puts the onus on anyone who disagrees with Haml’s jackboot aesthetics.
Sorry, but I’ve given it way more time than I would otherwise want to, because of a contract job I’m on.
I’m sorry Haml, I’m just not that into you. Please don’t get all obsessive weird Fatal Attraction on me, OK?
“Also the issue you mention with the response headers from haml’s site is just mongrel(the web server), that has nothing do with Haml. Haml is translated server side and in no way effects the response type from the server.”
My point was that Haml demands XHTML, when most people do not quite understand the larger XHTML picture, and the irony of a pro-XHTML site not bothering to send appropriate headers. A bit snarky, but it’s my site so I can do that.
Perhaps Haml should have an HTML4 mode.
“With html there’s pretty much one way to do it and it’s been the same way forever so why waste extra time on it?”
Such as invent a new syntax for people to learn when tools and experience already handle it?
Good question.
April 29th, 2009 at 09:38 PM
Why do you view indentation as restricting? You have to end your blocks anyways, it’s just a more formal way of doing it, more of a preference I guess.
You see no value in cutting your view code in half or easily embedding ruby into your view with…
== hello #{@user.name} welcome to #{@user.default_site} instead of hello <= @user.hello %> welcome to <= @user.default_site %>
What are your thoughts on Sass?
April 29th, 2009 at 10:08 PM
Haml has already different output modes:
Haml::Template.options[:format] = :html5for HTML5 or
Haml::Template.options[:format] = :html4for HTML4.
April 29th, 2009 at 10:16 PM
I’m the main developer for Haml, so I think I’m uniquely qualified to comment here.
First of all, it looks like your largest issues are aesthetic, and there’s really nothing to be done about that. A lot of people like how Haml looks; a lot of people can’t stand it. Some people move from the latter group to the former when they try converting a template or two, but if you don’t, that’s fine. Haml’s an alternate syntax for that very reason: some people like the alternative.
I think I can address a couple of your other points, though.
First, I think it’s a mistake to view Haml as a crutch for people who don’t know HTML. It’s impossible to use Haml properly without understanding the document structure it’s representing, which is essentially equivalent to understanding HTML. Many of Haml’s most fervent fans are designers, not programmers; they like the aesthetics and the parallels with CSS.
Second, Haml does offer an HTML4 mode, as well as an HTML5 mode. At some point I’ll get around to changing the website to make it clearer that it’s not strongly tied to XHTML.
April 30th, 2009 at 12:01 AM
/agree, don’t see what’s so gnarly about plain ‘ol html and have given haml multiple tries, but it just seems like another leaky abstraction layer…
April 30th, 2009 at 04:38 AM
I’ve used HAML in one of my side project and my feeling is, with HAML, tags are out of my way. When I write HTML (or HTML+ERB), I write tags, read tags, and struggle with tags and indentation. When I write HAML, annoyance of tags are reduced to minimum and I can focus more on structure of the document, change it as quick as I want. Also the integration with ruby code is good.
So far, my only complaint(probably due to my ignorance) is, how I can reuse chunk of code from same file or another haml file.
HTH
April 30th, 2009 at 08:24 AM
Nick: Compulsory indentation creates work to solve a problem I don’t have. It gets in the way of me doing things I want to do, such as apply distinct formating to create visual emphasis, or quickly cutting and pasting to move things around. I see it very much the same as the bad forms of static typing.
Also, the sins of Erb are orthogonal to Haml; I prefer Ramaze (and before that, Nitro) to Rails for a few reasons, one being how code is embedded in templates.
And I’ve not used Sass. Haven’t had a reason to.
Nathan: I don’t view Haml as a crutch for people who don’t know HTML.
Regarding the structure of an HTML document, Haml seems to insist I work with HTML as a fully expanded tree, rather than as a string of characters with embedded markup.
Sometimes (maybe mostly) the tree abstraction is what I want. Other times, string-of-chars is what I want. I like having that easy choice.
May 1st, 2009 at 12:59 PM
“This is quite handy when I want to insert something at the end of an element; from the start tag, hit %, and jump to the end tag. Perhaps this is also possible in Haml, but I’ve not figured it out.”
For indentation-only languages like Python, “set foldmethod=indent” and the various fold commands (zc, zo, zm…) are one helpful way to navigate in vim. As a bonus, this is useful for properly-indented code in any language, even ones with braces.
This is not to take away from your main point, which I tend to agree with.
May 1st, 2009 at 05:02 PM
I like HAML because it’s clean and easier to read… and yes, I’ll back that up with code.
http://pastie.org/private/n8ipfrkxlremo4jwtxiww
I just converted an older ERB view file to HAML in about 4 minutes… mostly hitting the delete key.
A 39 line code becomes 31 lines… and that’s not even the big win. Now if you don’t think the HAML code chuck is visually easier to read than the ERB version, that’s fine. Stay with ERB.
I find HAML code is easier to maintain & write… and it has nothing to do with a lack of knowledge of html.
What exactly do I mean by easier to write and maintain?
First, there is the overt clarity when it comes to sass (css) & haml code.
## haml file .container .header %h1 Site Name %ul %li= link_to ... %li= link_to ... %li= link_to ... .content stuff .footer## sass (css) file for this .container background-color: black .header background-color: white %h1 Site Name font-family: Funky %ul %li= link_to ... %li= link_to ... %li= link_to ... .content stuff .footerDo you see the pairing? I LOVE that! I find it clean & easy to read.
Secondly, it’s very ruby like.
This:
<% if @subscription.state == 'trial' %> <label>Trial expiration date:</label> <%= @subscription.next_renewal_at.to_s(:long_day) %> <% else %> <% if @subscription.amount > 0 %> <label>Next charge date:</label> <%= @subscription.next_renewal_at.to_s(:long_day) %> <br/> <label>Next charge amount:</label> <%= number_to_currency @subscription.amount %> <br/> <label>Current payment method:</label> <%= @subscription.paypal? ? 'PayPal' : "#{@subscription.card_number} / #{@subscription.card_expiration}" %> <% end %> <% end %>becomes:
- if @subscription.state == 'trial' %label Trial expiration date: = @subscription.next_renewal_at.to_s(:long_day) - else - if @subscription.amount > 0 %label Next charge date: = @subscription.next_renewal_at.to_s(:long_day) %br/ %label Next charge amount: = number_to_currency @subscription.amount %br/ %label Current payment method: = @subscription.paypal? ? 'PayPal' : "#{@subscription.card_number} / #{@subscription.card_expiration}"Which looks & feels more like ruby? For me, the choice is clearly the second one.
Anyway, to each his own.
May 2nd, 2009 at 11:33 AM
“Which looks & feels more like ruby? “
Neither, really, though at least with the erb code it’s far easier for a Rubyist to jump and much with the Ruby parts without having to worry about some additional meta-formatting restriction.
The latter looks more like Python.
May 2nd, 2009 at 07:28 PM
For myself, I’ve always been reluctant to use haml (or another such alternative markup language) for 2 main reasons:
1. Portability – I want to grab a snippet of html and pull it into another application. That app may be in Ruby, PHP, Python, etc. The fact, however, is that 99% of the time the framework I’m using in the other language uses html. I don’t want to deal with converting between one markup language and another. I want to just write a snippet of html and copy it directly into another project.
2. Shared knowledge – The majority of developers / designers I work with know html. If, for the most part, I’m developing both the backend and frontend, it’s probably okay to use an alternative markup language. But what if I want to pull in our designer or another developer or some outsourcing firm to help build the html / css for the website? Chances are they don’t know haml and I don’t want to go through the effort of converting their work into my alternative markup.
I do think haml is a cool project and I think it has its place. However, for the majority of software development firms, I agree with James.