Eh, different strokes for different folks. My only major criticism of Haml is that it makes me actively adverse to how incredibly verbose HTML is, which probably isn't a good trait for a web developer.
Yea, I know what you mean. I found a cool tool that lets me do all my prototyping in haml before having to do any real Rails coding: http://github.com/jlong/serve/
James is right on about where HAML falls short; but thats not HAML's problem, its more of a preference. I will be the first to say that HAML is no appropriate for everything. Here is how I apply various templating engines in my Rails projects:
HAML - Great for application markup (as opposed to document markup... see ERB below) for a number of reasons. (1) application markup tends to be heavy in javascript where you need a clean DOM. HAML reduces the chance of screwing up the DOM and makes it easier to look at during development. (2) Lots of conditionals in the view and I'm too lazy to factor them out into partials or helpers. Sometimes its just easier to express if/then and loops in HAML than it is in ERB... slightly less markup.
ERB - Document/content markup. If I have big docs with lots of links and paragraphs, but nothing to heavy going on thats dynamic/conditional, ERB is the easiest way to go.
Mix 'n' match! Then you can have the best of both worlds!
I have to say, as a professional web developer, that I've never found that "application markup tends to be heavy in javascript", or that I've "(screwed) up the DOM". HTML isn't particularly difficult, although things like HAML might prove that doing it well without a helper abstraction is difficult.
Code management (breaking things up into appropriate templates and fragments) trumps things like HAML for ease of use and clean separation every time.
I'd say his main points boil down to poor tooling and creating a solution for a problem that doesn't really exist... except that many of us do see issues with existing templating options and Haml+Sass works really well.
I will concede that it can cause friction with designers though.
I thought his point was that people who like it tend to be newbies to web development who are not able to make an informed critical judgment about its merits because they don't know enough of HTML to begin with - they learn HAML by seeing its output without understanding the HTML that underlies it. But I agree that this seems like a weak argument. I can't imagine working in web development without understanding HTML.
This was me until about the 3rd time I played around with Haml. Then it occurred to me how much noise I got rid of by using it, after which I was hooked.
Jquery + Haml is a very close impedance match and a real pleasure to use for development.
Take the following Haml that defines a div with an id of "foo" along with a span with class "bar" and content "Hello World":
#foo
%span.bar Hello World
If I wanted to hide those elements, I'd write the following jQuery in a separate file:
$('#foo').hide();
$('span.bar').hide();
That's really powerful stuff. The Haml syntax for defining elements looks exactly like the CSS3-style selectors used by jQuery, so much so that I often cut and paste my Haml markup into my javascript files.
Web designers often send me half heartedly formated html that is full of repetitive nested structures that I do not understand. When trying to turn it into a collection of partials I have inevitably destroyed some important tag. Everything breaks and I have to start over.
Turning it into haml has two benefits. I can visualize the structure of repeating elements so I have a better idea what to break into partials and I will never forget a closing tag which causes everything to break in some horrific way.
I agree with the author on editor support for closing tags. I often find myself noticing something is wrong when I tell the editor (emacs) to auto-indent everything and it doesn't look the way I expect it to. I also find ERB to be quite simple and straightforward.
This post is a negative critique of Haml which points out that it is not an improvement over HTML - it makes working with designers more cumbersome for one thing. A somewhat different viewpoint from a StackOverflow user:
