haml, an objective view
In the last few weeks, I have been introduced to haml, which is a different way to write you views in rails. My initial thoughts about it weren’t so keen, so I wanted to take a more in depth look at it to see why people are switching to it, and why, or why not, to use it.
First of, I can see why people are switching to it. It is generally felt that it is a cleaner way to look at your views. For example, this is what something simple might look like in rhtml
<div id="profile"> <div class="left column"> <div id="date"><%= print_date %></div> <div id="address"><%= current_user.address %></div> </div> <div class="right column"> <div id="email"><%= current_user.email%></div> <div id="bio"><%= current_user.bio %></div> </div> </div>
The same code, done with haml would be
#profile
.left.column
#date= print_date
#address= current_user.address
.right.column
#email= current_user.email
#bio= current_user.bio
So, what is the first thing that you notice about the difference between these two? Well, the first one looks a lot like HTML with script tags, which is pretty much what it is. The second, looks a little bit like CSS at first glance. If we take a little closer look, we also see that in the haml example, there are no closing tages. What haml uses is very similar to python in that is uses white space checking to end things.
Some people enjoy this a lot, the fact that they don’t have to explicitly end things, but this is the first thing that bothers me about haml. It could just be the type of meticulous person I am, but I want to explicitly close things, and make sure that nothing is missed when programming. If I learned from python, I am pretty sure that this wouldn’t both me as much. Being that because I learned java as my first language, I even feel weird not explicitly using a return from a function (this throw me for a loop for a while in rails). I understand that this isn’t a very solid reason to not like something, but from a strictly person preference, I do not like this, however I do see where many would.
The second thing that bothers me about haml, is that a developer might not understand right away what it is doing. Many times have I worked with other people on projects at school, and a few programming contests, and what would mess us up the most is one of us not having the knowledge base for something and the other person trying to use skills and techniques that the other person doesn’t know. When doing some larger projects, many times the programmer will get a developer to do the views for the project, and then just fill in what they need to with script tags and the such.
Yes, I understand that at first glance, a developer might be able to read haml, and understand what is going on, but if you want to use haml for the entire application, they will need to learn how to write it. This may not be a big deal to some developers, but it might be to others. Basically when it comes to learning anything new, some people can pick it up quickly, but some might not be able to. I guess this maybe a moot point, but one I wanted to bring up none the less.
So, in doing a little bit more research between the two, I looked at what other people had to say about the two. There was really only one strong argument as why not to use haml, and it was due to the fact that it has to be reparsed before rendered and that it is a performance hit. Some metrics someone ran showed it at about twice as slow. This may not be a good argument for a lot of projects, but for those where performance matters, it is a very compelling argument.
So, personally, I don’t see a fantastic reason to want to switch to haml. I see its advantages of being cleaner, but also the disadvantages as well. I guess, I should try it on an app once, and see how I like it, and then use what works best for me because honestly, I don’t want to use something that is extremely uncomfertable for me, but if I happend to like it, then it might be something I would want to use more often. Once I give it a try, I will post my thoughts on it, but with the exception of the small things I don’t like about it right now, I can’t see a reason to dismiss it before trying it.
Tags: Add new tag
May 29th, 2009 at 11:15 pm
I don’t think you really make much of an argument here. Your first point references the fact that it breaks a convention that you’re familiar with — which is fine as an argument against personal use. However, with new technology, that will only be avoided in situations where something is 100% backward-compatible. If you wanted to make an argument that ERB is a better tool because it is entirely backward compatible with static html pages, I will fully agree!
As to the second point, it’s not fair to use unfamiliarity as an argument against use. Some users may choose not to run Linux because of the lesser documentation and “hold your hand” tech support. However, this is not a reflection on the Linux operating system, but rather a reflection on the capabilities of the user, and what technology best suits them.
All in all, this is a subjective look at Haml, not an objective one. You lay out two good reasons why you — or another developer with a similar background — might decide not to use Haml, but only one comment regarding its objective peformance — the double-rendering.
Can you site the statistics on Haml’s performance, because I was under the impression that it performed on par with ERB.
June 1st, 2009 at 11:07 am
I understand your points, this is more of a subjective look at it. I do want to mention that even though you disagree with my arguments, I am assuming this means that you don’t disagree with my conclusion as you didn’t mention it.
As stated, yes, I personally have a few issues with it, but there was only one real point that I could find about haml objectively, and that was the performance issue.
As for your question about performance, here is a link
June 10th, 2009 at 5:24 pm
Haml is extremely valuable to speedy implementations of sites because you don’t get to launch your site with invalid markup, which means you won’t fight as much with CSS or JavaScript DOM parsing. That alone is worth the price, and it’s one of the chief reasons it’s become so popular.
If you’re concerned about performance, you need to look at other factors besides view rendering. On any site where view rendering performance is a concern, you simply implement caching, either fragment or action caching, or even static page caching, which is a good strategy to employ anyway.
Whitespace programming languages have existed for a long time, and they continue to do so because of the fact that you simply cannot get past the compilation stage if you don’t structure your code properly. Chasing down curly braces or if…ends in long files (or closing tags) is a lot of wasted time. Considering you read code ten times more than you write it, readability is vital to your success.
One more point: HAML is useful outside of Rails. You can use it to generate static web sites too using the StaticMatic gem. This removes the rendering cost. It’s also a great fit for Sinatra.
August 4th, 2009 at 1:29 pm
People that argue that HAML is cleaner and easier to read, thus saving hours of effort in “chasing down curly braces” must be used to sloppy markup.
As a visual designer as well as a front-end developer, I strive to write beautiful, elegant, simple, and very clean markup. I don’t see why this isn’t enough.
I also don’t understand the desire, and apparent need by some developers, to abstract something as simple as (x)html to begin with. I can understand abstracting a complex programming language, but (x)html isn’t a programming language and isn’t complex.