HAML: the unforgivable sin
The other day I posted this on twitter: “there are many mistakes I’m willing to forgive, but using haml is not one of them”. Many people replied asking me to explain why I don’t like it, so here it goes…
I have used HAML on several client projects, and every time it drives me nuts. While there are certainly some things that are nice about it, overall it is a net loss.
For abstraction’s sake
Abstractions are a beautiful thing. The goal of an abstraction is to reduce or factor out details that you don’t care about. By removing details, an abstraction allows you to focus on the problem at hand and not the underlying implementation.
But an abstraction fails when it doesn’t remove the details. HAML is purely an abstraction of syntax. I still have to think about tags, ids and classes while I’m writing HAML. It simply provides a more concise syntax.
So you hate SASS and CoffeeScript too?
No. While SASS and CoffeeScript do abstract the syntax of CSS and JavaScript, they provide other great features.
SASS (or even better, SCSS) is a great abstraction because it enables features that would be nearly impossible to maintain by hand. It makes it easier to break your styles up into small, reusable components, and encourages good design patterns.
Likewise, CoffeeScript adds “features” on top of JavaScript that are extremely cumbersome to code by hand. CoffeeScript guards against common coding mistakes, like ensuring variables are properly declared within lexical scope.
Easy to write, hard to read
I agree that HAML is easier to write than HTML, simply because it involves less typing. But I feel it is infinitely harder to read. While the indentation makes it easy to see the nesting, the extremely overloaded synax requires careful attention to each line.
If HAML provided some value other than saving a few keystrokes, I would likely become a believer. But it doesn’t.
Typing is not my bottleneck in coding. Thinking is. And forcing my brain to parse HAML when it is occupied by more important things is not conducive to productivity.
44 Comments
Hey Brandon, nice point on being careful about what abstractions you use and making sure they add a benefit.
I still like to use haml because of how strict the syntax is. It’s been a benefit for me to know that tags close correctly; sometimes it can be tough to find a missing closing tag in erb.
Haml can been frustrating, though (tab/spacing errors for example), but it has also forced me to remove more logic out of the view into helpers or presenters.
So I discussed this with everyone at my company and we collectively decided that this entire sentiment is incorrect.
Matt: This has been my experience with it, I’d love to hear how yours has been different.
I like HAML ( or even better SLIM ) because it directly represents what HTML ultimately results in; a DOM. SLIM and HAML have a similar representation as to what you see in a DOM inspector.
Thank you so much for writing this. I tried to “get” HAML for ages but it’s main flaw is in the abstraction and the fact that you can’t easily reverse-engineer any tutorials for stuff you want to do with complex HAML. I just do not know where to look.
I like HAML because I find it easier to both read and write than HTML. Whatever works, I guess.
Have you tried SLIM? I hate HAML but love SLIM. Everytime I tried to use haml, I failed. It was nice to look at but hard to use. The syntax was non intuitive. Slim on the other hand has been pure bliss
I agree with Manu, SLIM is great and much more readable :)
I haven’t tried SLIM, but it does look interesting. I like the syntax better than HAML’s, but syntax isn’t my biggest issue with it. My hunch is that I will feel the same about SLIM as I do HAML. But I’ll give it a try.
I completely agree!
I’ve been working on a project for 4 months that uses HAML religiously and I still haven’t come to grips with the markup. Granted its much easier to write but it’s like learning a whole new language that really doesn’t have any benefits.
You’re right on the money.
I have to disagree. I agree that HAML isn’t as much of an abstraction as CoffeeScript or SASS (btw, I also love CoffeeScript and prefer SASS over SCSS), but the “easy to write, hard to read” sentiment couldn’t be further from the truth for myself (and likely others that enjoy HAML). Most of HAML’s syntax is borrowed from CSS selectors which helps remove the cognitive dissonance that results between HTML and CSS. This is part of the abstraction of HAML that does allow you to get closer to the problem at hand — rendering a beautiful view or layout. To me, HTML adds enough cruft to the underlying data, and ERB adds even more. HAML cuts that all away allowing for a more concise view, and in my opinion, a much easier-to-read syntax.
We’ve been using HAML for almost 3 years now. I was very resistant to it initially for the exact reasons you listed in your post. But, my team was insistent in using it back in the early days so I obliged. After the first several projects I began to actually find HAML more descriptive. When you are trying to write semantic html and you are looking through javascript and CSS and relating it back to the HTML, it is much easier in HAML to find the dom elements because you aren’t parsing attributes in a sea of div tags. HAML distills the meaningful parts of your markup down to what is important. I’m 100% sold on HAML now.
Ryan: I do love that the syntax matches up with CSS. It makes it so easy to do project wide search for classes and IDs. But it’s never gotten easier to read for me, and it feels like more cruft instead of less. But maybe my brain is just backwards.
I appreciate this thoughtful writeup. I don’t mind HAML, but I think you make some good points.
Matt: Keep trollin’, son!
Hmm, I’ve been using HAML for several years now, and I love it.
To me, ERB is the thing that is hard to parse, with all the close tags everywhere, and when I have to work on a client project which uses it, it slows me down slightly. It’s just what you are used to!
I’m a big HAML fan, because the beestings make my eyes hurt and seem pretty daunting to parse, and doing anything out of the ordinary in a view seems to stick out more in HAML than it does in ERB.
I haven’t used many other rendering engines though, so my opinion’s somewhat limited.
Haml does add some nice features beyond just syntax, in the way of filters. It’s pretty nice to have embedded Markdown in a template.
But I recently switched back to ERB after a couple of years using Haml, because I found that it was much easier to read & scan well formatted ERB.
I agree that initially HAML is a bit odd to write, when you’re used to plain HTML with ERB tags. I was also a bit hesitant to use it at first and I do love writing plain old HTML.
However, once I got my head around it (thanks to a bit of Python experience), it seems to me there are some notable added values to HAML over ERB:
I think that your assertion that HAML should offer abstraction is a bit misguided, as its simply another template engine and like many other great things in the Ruby world, you either love it or you hate it :)
I like absolutely nothing about the HAML syntax. I’m so thankful I found SLIM !
The first time I tried HAML, I had the same reaction. As I worked on more and more projects where it was already in use, I became frustrated. Eventually, I decided that HAML gets particularly hairy if you aren’t abstracting logic into partials and helpers where appropriate. In small doses, it’s fine.
At Factory Labs, we’ve been slowly migrating from HAML to Slim. There is less syntactic noise per line, which ultimately means it is more readable. Give it a real shot — I think it’s a huge improvement.
I think your argument is good, except I disagree with your basic assertions.
Abstraction:
I don’t think HAML is an abstraction of HTML – it’s more an abstraction of the same thing that HTML is an abstraction of – the “document” as it is understood by the browser. (The fact that it compiles to HTML in the middle of the process doesn’t impact the programmer much.)
The reason that this different abstraction of the document is needed is because HTML doesn’t have conditional bits or the ability to iterate over an array or even throw in a bit of text from some variable.
ERB solves this by (it’s right there in the name!) embedding Ruby into your HTML. Now you have two very different languages that want to be indented in mutually exclusive ways.
Readability:
HAML, while it borrows from Ruby quite a bit, also enforces its own syntax on even the Ruby-ish parts. This allows you to indent your code in ways that make sense for the entire document.
And even ignoring the complexity introduced by ERB, I think HAML is a better abstraction than HTML. To me it is more concise and readable.
I think haml has better readability, is faster to write, and reduces the chances of unseen html errors.
I believe you when you say you think it harder to read.
I’d liked to see an actual example of “the extremely overloaded syntax” thrown in a gist.
For the sake of disclosure I should state I’ve only used raw HTML, ERB and HAML.
With that said, I love HAML. There’s so much noise in reading HTML (and ERB is barely better) that scanning HAML is lovely in comparison. I don’t think I have a single problem with it that I can’t lay at the feet of HTML also. I like that it fails early – I can’t forget to close a tag, I can’t be unclear about the parent / child relationship between any two elements, if HAML parses chances are good (or at least much better, for me personally, than with handwritten HTML) that it does what I intend it to.
But then I’m one of the few that really likes Python’s indentation system as well, so maybe there’s something of a pattern there.
Couldn’t agree more with this post… I recently turned down taking over maintenance on a large Rails project as all of it’s views were using haml and rewriting them so that everyone could understand what was going on was simply wasn’t an option.
Count me in the group of people that find haml much more readable than erb. The fact that it saves some typing is completely secondary to me.
Pete Browne: good point on filters.
Neal Lindsay: Interesting perspective. I hadn’t thought about HTML just being an abstraction of the DOM. The difference though is that HTML is a useful abstraction: it makes the DOM portable. HAML being purely an abstraction of syntax is not enough to make me like it.
Thomas: I actually love the idea of significant whitespace. Every language has conventions, so why not enforce them? I like Python and CoffeeScript for that reason.
I’ve actually found HAML much easier to write AND read through. SLIM, however I’ve found harder to quickly parse visually, so reading it is a lot slower IMO than reading HAML.
I’ve used HAML in several projects, too. One thing is true: You’ll have to think while coding. But on the other hand code looks cleaner to me.
I also avoid HAML like the plague.
It does not add anything but change the syntax. If you think it helps you find non closed tags you need to pay more attention to what you type and use standard markup validation.
Its a fad.
Ha, this sparked some conversation. Thanks for sharing your thoughts Brandon. I think it is great everyone feels strongly one way or other. It really comes down to using the tools you work best with. A really good friend and colleague is staunchly against haml as well; we always have to chat about whether haml or erb is better for the project. Sometimes its one way or the other.
But then again, that’s why there is test unit, mintiest, rspec, haml, slim, etc.
I find HTML encourages you to think about the DOM as an XML document, while HAML encourages you to think about it as a tree of nodes with types, classes, and ids. As web developers, we should be thinking about it the second way, which is the biggest reason it resonates with me. The other thing is if you are using sass, there is this really nice symmetry between the way your styling file looks, and your markup file looks.
That being said, I am starting to dump haml as well, but for moustache. I find moustache has a very elegant syntax, keeps me honest with keeping logic out of the view, and most importantly is pretty much the same thing on both client and server side.
HTML is really hard to write, you know, just a handful of tags that are used in an application, so surely we need code to write code for the sake of being programmers. I think HAML is hard. I am going to write a pre-processor that writes out HAML, which can then write HTML. Efficiency!
Let’s not even talk about teams where UX is well versed in HTML/CSS and don’t feel the need to learn HAML for something that is easy and readable to them in the first place. Why deal with the learning curve that’s unnecessary? Especially if it’s a contractor or contracted UX team, that works on applications outside of the Ruby/Rails ecosystem.
I’m not bitter, I promise :)
I think a lot of programmers also end up handling the markup themselves. I typically work with UX teams and front end coders. These guys are usually more familiar with HTML. They are used to code examples in HTML they deal with browser issues all the time. They use firebug and such which shows them the full markup.
I can understand and appreciate the benefits of HAML, but can’t say I’ve been in many situations where it would have been beneficial. I can see where people in a more closed environment may have an easier time adopting it.
Sometimes the more elegant and simple solution is what you have in the first place.
HAML is the white bread of front end code. Yeah, I said it.
I’ve never cared for HAML, but love SASS/LESS. SASS/LESS simplifies writing maintainable CSS. Your point about HAML being difficult rings so true with me: I find it unnecessarily difficult to read. A template language like mustache or handlebars feels much better to me and is easier to read and write.
I’m still on the fence with CoffeeScript. It does simplify some aspects of the syntax, but there’s several parts of it that I’m not too crazy about too.
THANK YOU.
Every time I say this to someone I get a lot of hand waving about “speed” and “efficiency” benefits or whatever, but you hit it on the head: typing isn’t a bottleneck for me. Then again, I come more from a design background, so perhaps that’s why HTML feels more at home to me. :)
I agree on HAML.
And yet, I also prefer ‘builder’ to ERB for XML. ‘builder’ is a much more HAML-like syntax (yeah, significant differences, but similar in the extra abstraction and even the nature of the abstraction, you aren’t writing actual tags in your template, you’re writing methods that create tags, like you effectively are in haml too)
I can’t not explain this contradiction, why would I want/not-mind the extra abstraction when writing XML but not HTML? I can’t tell you. But I do. Curious if you agree.
The problem is that browsers will parse and display syntactically invalid HTML.
Sometimes they display what you want, other times (okay let’s face it, any time in IE) it displays garbage, and it’s a pain to debug. Haml either compiles or it doesn’t, and it generates correct HTML.
I like Haml because I dislike angle brackets, and I dislike subtle HTML bugs.
Your arguments against HAML can equally be targeted at SASS. Similarly your arguments in favour of SASS are just as valid for HAML.
However, to summarise the benefits of HAML as “it saves typing” is a pluto’s orbit away from what it actually offers.
I think what you are really trying to say is that you just don’t like HAML, but why post a blog entry so short and non-controversial ?
I think it is a matter of personal preference. After getting accustomed to HAML I cannot image going back to HTML or even Erb for doing websites. My observation is that it is much, much easier to read and parse HAML in mind than it is HTML/Erb.
Writing HTML isn’t very difficult, especially if you use something like Zen Coding
Validating and debugging HTML is also pretty easy and there are plenty of tools available to help. I personally prefer HTML since that’s what the browser is actually going to parse and that’s what I see when I’m using a tool like Firebug. But I totally get that some people don’t like HTML and HAML is a way to avoid it.
I don’t have any issues with HTML so HAML to me is an unnecessary abstraction.
I’ve used HAML for 3 years now and I’m also forced to use HTML just as much for PHP projects. It’s painful to use HTML and a joy to use HAML. I hate typing <%= %> and I find this elegant:
- @posts.each do |p| .post %h2= p.title .body= p.body.html_safe
Thanks for this post. HAML absolutely drives me nuts!
“Typing is not my bottleneck in coding. Thinking is. And forcing my brain to parse HAML when it is occupied by more important things is not conducive to productivity.”
Excellent point. Typing isn’t my bottleneck either but parsing out all the noise in HTML is.
It takes me a fraction of the time to read HAML than it does to read HTML for the simple reason that it’s cleaner. I can better see the meat of the context without all the redundant noise and often poorly formated HTML.
Which brings up another reason why I like HAML so much. It forces people to write clean code. One of the first things I have to constantly do when reading almost anyone else’s HTML is clean it up and fix indentation. With HAML you are forced to write consistently clean code. I like that.
All that being said if you want to use something that, to me, is noisy and difficult to read I would hardly call that an unforgivable sin. I’d just say you have a different opinion. It’s neither right nor wrong it’s just different and that’s OK.
I tend to agree. I have used HAML and ERB on various projects and I can’t say that HAML has revolutionised my productivity. I think it comes down to personal preference, whether you’re working on a legacy codebase and what the others in your team are comfortable using.
I don’t sign-up to the idea that HAML syntax is beautiful, for one thing. I find that we have a lot of lines in our HAML templates that are probably too long for one line, but are kept on the same line to avoid syntax errors or using pipes.