Are you using Haml?

If not, why? Seriously, take a moment to tell me in the comments. If you haven't had a chance to play with Haml yet, here is an easy opportunity to do so online.

All of Hashrocket's new projects are done in Haml, and we've now decided to transition everything else in our portfolio over to Haml as soon as possible. The indentation-based approach works wonders for generating clean, semantic markup and the way that you can see the structure of your markup in a way that easily maps to CSS rules is simply brilliant.

My initial impression of Haml was not as favorable. If you similarly gave Haml a try when it was originally released and couldn't get it to work in a stable fashion, you might want to try again.

Comments

[Jeff Casimir]

Whenever I come across an old ERB template that needs editing it is hard to resist rewriting the whole thing in HAML. I think there are probably some processors to do the conversion for you, but often in the reparsing I find small elements to add or correct - such is the clean elegance of HAML.

[Matt Bauer]

I wonder who suggested using HAML?

[Norman Clarke]

I haven't used it. My first impression was that it is pretty, but adds more complexity without really offering much more than I can already easily do with XHTML and ERB templates.

By more complexity, I mean that I have to work with designers who are not programmers, and I think using an alternative markup may make it harder to collaborate with them. As it is now I can just send them my ERB templates because they're generally vanilla XHTML/CSS with a few ERB tags thrown in.

I would be perfecty happy to be proven wrong/persuaded to use it though.

[Phil]

I'm pretty happy with Markaby for projects that don't need a separate non-rubyist designer. It's much easier than ERB in terms of tooling as it's very difficult to write a parser for Ruby (or anything) embedded in HTML. Being able to stick with ruby-mode across the board is handy. Plus using stuff written by _why gives me the jollies.

[Luke Francl]

I've used it on two projects. I find it hard to read and I was disappointed that it didn't offer substantial features over Erb, like auto-escaping HTML. I find the indentation argument to be a non-issue for the most part, because I usually view my HTML source using Firebug.

[Tim Connor]

"that easily maps to CSS rules is simply brilliant"

Ahhhh. I never played with it, really so didn't notice. I blew it off based on the extra line noise over Markaby (and I liked the idea of writing my templates in ruby), but now maybe I'll take another look.

[Daniel Fischer]

I got everyone using Haml at our consultancy. I even wrote a couple (newbie) tutorials on how to get running with it.

[Paul Barry]

I love HAML and use it on projects that I work on by myself or with others who also like HAML. But I agree with Norman, I find that if you work in a larger group with designers who are used to working with ASP/JSP/PHP and they are not really programmers, they are already used to the ERB model. Designers who are really into CSS seem to like HAML more.

To help with HAML adoption, it would nice be nice to see the HAML Rails plugin be smart enough to override the default Rails scaffolding and generate HAML templates instead of ERB, similar to how RSpec gives you the rspec_* generators.

[Jean-Francois Couture]

It's slow. I tried 1.7 a couple months back. They say it's around 30% slower (even better with haml 1.8) but benchmarking with my own views showed that it was 3x slower. It appears that haml slows down quite a bit if you use lots of partial: http://nex-3.com/posts/58-caching-with-haml
(look at the benchmarks at the bottom).

Otherwise, I love to use it.

[Tammer Saleh]

I've just started using HAML on my side projects, and I'm a convert. We had stayed away from it at Thoughtbot because we were working with a lot of out-of-house designers. We didn't want to introduce an unnecessary obstacle there. I'm probably going to bring the subject up again, now that we have our own design team.

HAML's not perfect, though. I was stumped for a bit on why textareas were showing extra whitespace before each line. Same with textile code blocks. Both of those were easily fixable with ~, but it just illustrates the point that no new tool comes without a bit of a learning curve.

[Erik Peterson]

I like Haml in general but there are a few issues that prevent it from being great. You have to use the crazy "succeed" hack to follow tags with punctuation, which breaks up the flow of your code and is completely backwards from intuition. In general, when using Haml, I'm much less likely to structure sentences that end in links or bolded or italicized text. When your markup changes the way you write, that's generally a bad thing.

It would be nice if indention were optional for certain tags, like a, b and i, and that with inline tags following whitespace was omitted. It really throws things off when you have to do:

%p
So I was walking through the garden and there was this
%i huge
=succeed "!" do
%b bug
And I got
=succeed "." do
%i scared

Just try reading that. Not very elegant. (Sorry about the indentation)

That said, I still like Haml and use it, but there is definitely some room for improvement

[Hampton]

Thanks for the great comments people. And thanks for the plug, Obie!

@Erik:

That is not the way I solve that problem, however that is *a* method.

We have a "command" called == that basically builds in string interpolation right into the line. (Spaces are totally warped here)

%p
So I was walking through the garden and there was this
%i= huge
%b== #{bug}!
= succeed "." do
And I got
%i== #{scared}.

So, for that example, that's how I'd solve the problem, as-is. But to me, it points out one of the design philosophies that we stick to... I don't often find myself writing code like that. When I have plain HTML text like that, I tend to just use markdown or something and write it that way, or I write inline tags. If I was writing a MadLibs style thing as above, I'd probably want to meta-program it in some sort of way in my models. Maybe create stories that can be told through the site.

So, == works for most times when we want to format a line and *not* have the model do the formatting of some data. And as for contrived examples where you'd use that all over your document, I think you should take a moment and re-think your technology choices. I mean, maybe for a huge page like that, Haml *isn't* the answer since you aren't doing any structure work.

Haml is for structure. It sucks at doing inline formatting... so don't use it for that!

But, that doesn't mean its not useful in many other places.

[Nathan]

My brain has been trained to scan and pick out information from HTML for 10 years. Take a look at the example here and scan it http://lab.hamptoncatlin.com/play/with/haml... then click the render button and scan the results. Which is easier to scan? I prefer the HTML

[jason]

Started using haml but opted out.

Found it painful to use a new syntax other than plain HTML.

HTML is very clean, simple and does exactly the job I want. Not convinced it is useful or worth the effort to replace it with anything else.

[Mirko]

I've been meaning to give it a shot. My initial reaction was not that positive either (from using HTML for many years), but on second glance it does seem cleaner and less verbose. I'm currently working on a Facebook app and need to render FBML rather than straight HTML. I wonder how easy it would be to extend HAML to render FBML tags. Probably not that hard.

[Osama]

I came across this language 3 months ago. but I stopped for a while!

why?
well, if I keep on this way of learning markup languages then I guess - but sure - will have more than 20 markup language in my pocket at the end of year 2008.

I prefer to slow down these days. and see what is the best fit language for my upcoming projects.

[Eric Anderson]

Erik: Your example does illustrate how thing can be a little awkward if you let them but often there are alternate ways to do things that are much more readable. Hampton mentioned using the == operator that helps a lot. Also if your content is just formatting stuff then I find the filters to work well. Just put some content through textile and markup the text with textile formatting. Using your example:

:textile
  So I was walking through the garden and there was this
  /huge/ *bug*. And I got /scared/.

This is much more readable although admittedly it is cheating since you actually aren't using HAML to markup the code but since filters are so easily integrated I think it is an acceptable solution.

[Jim Garvin]

I have two projects I spend most of my time on, but only one of them uses HAML. I would *love* to redo the other one in HAML, but that's not in the cards.

I use Textmate, and since I still do a fair amount of normal html.erb, I'm accustomed to using the Cmd-Shift-. command to close tags. I smile to myself when I'm in a HAML view and I reflexively slap Cmd-Shift-., and nothing happens. So cleeeeeaaaannnn...

If you've been hand crafting HTML/CSS for many years, then I think the benefits of HAML/SASS should be apparent.

In response to the earlier comment that HAML is a bad choice because designers can't/aren't able to work with it: I had *exactly* that experience. A designer in my company, dreamweaver guy, was very resistant to learning anything new, especially HAML. I am glad that I did not allow my project to share the limitations he places on himself. He ended up spending the 30 minutes necessary to grasp HAML.

You should not embark on a technical career with the mindset that what you learned in your first year is all you'll ever need. HAML reduces the amount of code necessary to express the same information as XML, and gets rid of the redundancy and some of the noise. That's progress, baby.

[Vince]

ruby only? what if someone wants to use the template with another language?

[Peter Krenn]

I tried out haml for some projects and really liked it's syntax. But I had problems with statements like:

Name:
= name

it's not the same as "Name: %= name %" in erb. Haml produces a newline here. And

= "Name: #{name}"

is not as readable.

I had situations where whitespace broke the layout of the page in some browsers.

[Jim Garvin]

@Peter Krenn:

You can use == instead of = for easy inline interpolation. eg:

== Name: #{name}

Notice this obviates the need for surrounding quotes. Check the docs for more.

[Finn Higgins]

Haml has a nice syntax and works well. But from my perspective it suffers from the same major problem that irritates me about the Rails erb views: the separation of view code into layouts, partials, helpers and templates. That's four concepts for essentially one thing: a view with nestable components. It also has a very counter-intuitive syntax for most designers, who're not as in the habit of learning new markup languages as developers.

I actually really like Hobo's DRYML view language. It solves both of these issues: it uses XML syntax and has a single concept of user-defined tags, which can be declared in libraries and reused. Plus it negates the need to write Ruby helpers for the most part, since the tags essentially compile to helpers anyway.

That seems to me to be so much cleaner than having a million oddly-named partials littering your project plus having to scatter your controllers with layout declarations.

[Aaron Farr]

I've chosen not to use HAML because HAML is this odd hybrid between a template language and a lightweight markup language. It's a tight coupling that turns me off for some reason. I'd rather use a general purpose template language to generate the specific markup I want than have half a dozen different ways to template HTML, Javascript, XML, etc.

[Bob Aman]

I've been working on a new framework on top of Rack, and while it supports whatever template language you happen to want to use, Haml is the default as well as what's used internally for HTTP error responses.

[Alan Simpson]

I tried HAML, but I really don't like it. It doesn't offer much, and it has several disadvantages, such as 1) You and every other developer you may work with need to learn a new syntax. Why add that extra hurdle when erb does the job and will already be understood. That wouldn't be so bad, since it is pretty simple to learn, but
2) I *hate* it when syntax is dependent on whitespace. The idea of debugging code by counting how many 'nothings' there are in a line is just insane.