I have been developing in table-less HTML for the past eight years. I can say I have a pretty good grasp on its syntax, how it is handled by the browser, what it can and can’t do, and even starting to understand the current HTML5 spec as it is in transition of becoming adopted. That being said, I am always looking for helpful tools to not only make writing HTML quicker, but strengthen my knowledge of the syntax and structure.
Enter in HAML
I first came across HAML about two and half years ago working as a contract developer for Outside.in. They were using it interspersed in their app to create their HTML markup. At the time it was very foreign to myself, but I muddled through it and then ended up moving on to other projects with out using it again until now.
So what is HAML?
HAML is a markup language designed to parse finalized output to HTML in Ruby on Rails environments. It has roots in YAML in that it bases the output on tab indentions to separate its blocks. Its main principal is that “markup should be beautiful.” I would take that a step further in saying that markup should be beautiful and quick to write. HAML, to me, does just that.
Let’s take a quick look at some basic HAML markup compared to ERB:
HAML
1 | #my_page_block |
2 | %h1 Hello! |
3 | %p Welcome to my page and have a look around! |
4 | %p.date= print_date |
5 | = link_to “Read more!”, “http://chrissloan.info” |
ERB
1 | <div id=“my_page”block”> |
2 | <h1>Hello!</h1> |
3 | <p>Welcome to my page and have a look around!</p> |
4 | <p class=“date”><%= print_date %></p> |
5 | <%= link_to “Read more!”, “http://chrissloan.info” %> |
6 | </div> |
Notice how much less markup is actually needed to create the HAML file. No more do you have to worry about unclosed tags; HAML does all that for you. Of course there is a lot more verbose syntax that comes with HAML, but it is very simplistic in nature.
So what is all the hubbub?
As I stated in the intro, there seem to be two sides to using or not using HAML in projects. After combing through many a blog, I have come to find the same cases for arguments crop up. This is in by no means trying to persuade whether or not to use it in your next project, but more of an understanding to why I started to use it again.
Issue: Causes div-itis (creation of unneeded markup)
Using it actually makes me think about my markup and structure before I write it. I have found that using it and its visual hierarchal structure allows me to capitalize on the cascading ability of CSS. Also, with the adoption of HTML5 to the mix, allows for div-itis to go out the window.
Issue: Comes with a learning curve
I do agree that there is a learning curve, but that is true to anything newly learned. When I first started having to use it, I found it odd and eventually abandoned it as I didn’t need it anymore. Now, with a few projects under my belt using HAML, it almost comes second nature. Switching back and forth from HTML to HAML seems a little cumbersome because HAML is much cleaner and less code writing.
Now I know someone will clamor about how HAML is not HTML markup and thus completely pointless to knowing HTML or loss there of. As I mentioned above, I have been working with HTML for a while and am very comfortable writing in it. I am not losing that ability by using HAML; just gaining a tool to excel my code writing process. It’s like riding a bike.
Issue: Team members must know how to use it and adopt it to their work flow
One of the hardest things adopting to HAML is to get the rest of your team to use it. If you are the only one on the project that touches view code, then no sweat off your back. If your team consists of other designer/developers, then yes, you need to present a very convincing case. Hopefully they will see the pros outweigh the cons.
I actually work with some other developers on side projects and they were very open to using it. One even told me it’s a lot easier to read.
Issue: Not typical HTML markup and syntax, but produces the same thing
True, but this can be said about just any language/syntax that is used to accomplish an end goal. PHP ends up doing the same thing as Ruby, but in a different manner. It’s a matter of choice for the developer and what they are comfortable using. If it gets the problem solved and in a timely manner and everyone is happy, I say use it.
So where do you stand?
Like I mentioned, I am not trying to persuade the developers that stumble upon this post to use it or not. This post was more for me to justify my means of adopting it and to really figure out the root cause of all the two sidedness to using HAML.
Feel free to leave how you feel about it or even if you use it in your projects how it has changed your work flow. If you don’t know about it, I challenge you to find out more and possibly try it in your next project.