It meant that we found developers willing to play and learn with the latest and greatest things, and they knew that we were a company that would be willing to let them use them.

Anyway. The heated discussion this issue raised both on Twitter and in the comments here is, I think, my point. I agree with James in general about haml not being for everyone, although I think the number of people it’s not for is bigger than you might think. And with that in mind it makes haml difficult to use in a team environment of any size, or one that wants to grow and not alienate potential hires.

HAML is for clearing the minds of people who create website/applications.
I would actually agree with Brad, it’s probably not for him. His job, I believe, really is to dive into the absolute depths of the HTML source, to cater for millions of users. His mind is in the raw source. This isn’t a very common job though.

HAML sits for all the people in the middle, of which there are many. They know HTML, they may even know HTML very well. But they don’t worry about obscure browser quirks in Netscape 3 or JAWS 6. And at this it does exceptionally well at enabling these people to create better HTML easier.

I can’t say I’d ever use Haml in a wire protocol though. It’s a tool for writing templates in the back end, not something that should ever go over the wire. The comparison isn’t really between html and haml, but between html and rhtml (or html.erb, or the HTML + the Perl template toolkit, or whatever else you’re using in the backend). In that domain, haml wins big because of its narrow focus. It’s not trying to be a general templating framework, just an expressive notation for generating well formed html programatically.

Regardless: to me, markup is interesting. I spend a good deal of effort honing my HTML for the end user (because accessibility and optimisation are primary parts of my responsibility), and the level of control I have over hand-coded HTML is vitally important to me. Not to mention that I write the kind of markup that doesn’t have as many DIVs as Haml is obviously meant to cater for, so it doesn’t end up even that much more concise anyway, since I’m always throwing in additional appropriate attributes (@title or @alt, for example).

As for Sass, well, the indenting saves me virtually nothing as far as typing goes, and makes it all too easy to break the cascade by using incorrect indentation levels.

Again, these tools are solving issues I don’t have. About the only moderately compelling argument I’ve heard here is that it helps defeat malformed-ness issues with abstractions like Textile or Markdown from the end user. In that sense, Haml, while being potentially more useful, actually makes less sense in 90% of applications as it doesn’t map as well cognitively to an inexperienced end user’s formatting experience. In their experience 2 new lines == a paragraph, for example, and Haml doesn’t really help solve this. Which just leaves it good for exchange of HTML-formatted data over something like an API (the other major un-trusted source), and it’s not really fit for that as it’s not a data exchange format.

Haml maps 1:1 to any well formed HTML. About the only thing it can’t do is generate badly formed HTML (unless you’re doing something dodgy in the bits where you call out to ruby). I use it not because it’s quicker to write but because, once you’re over the (short) learning curve, it’s easier to read. There’s less noise from end tags, it’s impossible to indent deceptively and the compactness of the notation means that there’s more data ink per page. Haml is not an abstraction (well, not in the sense that Textile is an abstraction), just another notation for the same DOM tree. Don’t like it, don’t use it, but don’t go flinging rhetoric like “Evil” and “shitty” around.

You’re welcome to spend mental effort making sure that all those useless bloody closing tags match up if you want, but I’d rather spend my time thinking about something more interesting. Sure, it’s easy enough to write HTML the first time in TextMate, but the tools are less wonderful when it comes to changing that markup.

In the context for which it was designed, Textile is fine, especially when you realise that just because Dean Allen decided that h2. Foo should render as

Foo

doesn’t mean you can’t decide that, in your application, it should render as

Foo

. The separation between a humane notation and its final HTML representation can make things a little more malleable, which is no bad thing.

Actually, without changing Textile at all, you could write h2(#foo). Foo and get an id on the generated tag anyway.

HAML also wins in the “Vertical space is precious” stakes.

.special#primary Hello, world

is just another way of writing

Hello, world

but it does it with way less noise.

When it comes down to it, it’s only syntax. If your grasp on the domain is so shaky that you’re going to be thrown by a different syntax for expressing exactly the same semantics, then maybe you don’t understand what you’re doing well enough either.

Seriously, what’s to know about HAML? If you know CSS selectors, can recognize the structure in the indentation and are told that tagnames are specified with %tag, with a %div default, you pretty much know everything about the notation. At least, when it comes to expressing XHTML – if you want to make use of the templating features there’s a bit more to learn, but even that’s not exactly rocket science.

Personally, I like the way Sass nesting reduces repetition too, and the variable interpolation and calculation features strike me as being sensible too. Names are power, and naming a color for what it means in the context of the site is just a good idea, especially if you might end up with two things having the same colour but for different reasons. The DRY benefits are pretty obvious too.

As always with these things though, mileage varies. Haml is interestingly different from, say, textile are markdown because it’s information preserving. In principle, it should be possible to write a tool which can go from well formed xhtml to HAML and back without losing any information and without having to stash any extra information anywhere. When the notations are equivalent in this way, the choice of which one to use becomes a simple matter of taste.

Sass would be pointless if it were just a mapping of CSS to something in Ruby/YAML. If someone is using it to generate CSS programmatically, that’s clearly a different story. It could be a good way of helping to write really complex CSS files, as you’d have to repeat yourself much less. But for 98% of uses, what’s the point?

Olly touched on the other key benefit; that it makes good markup more accessible to back-end coders. Most non-HTML-coding-coders I’ve met tend to use HAML or SASS for this reason.

It seems like a nice library, but I actually quite like markup, so I’ll stick with that ;)