In his excellent introduction to Haml, Dan Grigsby introduces a play on Greenspun’s 10th Rule of Programming: Grigsby’s First Rule:
“Any sufficiently complicated rhtml partial contains an ad hoc, informally-specified, bug-ridden, implementation of half of Haml.”
So, what actually is Haml? According to Hampton Catlin, Haml’s inventor:
“Haml is a rejection of the status-quo in XHTML generation. Its not pure code, nor is it a text processing language. Its something different. A way to build XHTML the way that I feel is most natural to the problem domain.”
In addition, according to the Haml site, “Haml takes your gross, ugly templates and replaces them with veritable Haiku.” Let’s take a brief moment to explore what is meant by ugly templates, and what is actually considered to be veritable Haiku.
Here’s an example of an ‘ugly template’:
<div id="profile">
<div class="left column">
<div id="date"><%= print_date %></div>
</div>
<div class="right column">
<div id="email"><%= current_user.email %></div>
<div id="bio"><%= h current_user.bio %></div>
</div>
</div> As you can see, it’s just a standard html/erb snippet. It probably doesn’t even look that ugly to you. However, and Grigsby explains this wonderfully in his article, there is not only a lot of repetition, but also a lot of unnecessary characters. Hampton believes that markup should be beautiful. And not any kind of beauty, he means the kind of beauty that makes you faster; the beauty of efficiency. So, in that spirit, the same snippet represented in Haml is as follows:
#profile
.left.column
#date= print_date
#address= current_user.address
.right.column
#email= current_user.email
#bio= h(current_user.bio)
Now, that might look a little strange, but you have to admit it looks a lot slimmer. Notice the use of significant white space to remove the html closing tags, the css style syntax to describe div ids and classes, and the removal for the need for awkward <%= %> tags. If you’re to count the number of characters used, the haml version in this example is 64% the size of the html version. This means 36% fewer characters to type, and 36% fewer characters to read. Essentially 36% less noise. Antoine de Saint-Exupery may well have been considering Haml when he said that “Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.”
There are mixed responses to Haml. A lot of Rubyists seem to compare it with Python, purely because of the use of significant white space. However, Hampton has never written a single line of Python, and just feels that whitespace can be a very good way to represent structure in documents. He sees Haml as being much more like YAML than Ruby due to its focus on document structure and data configuration.
There is always space for new ideas, and DHH agrees: “I’m not sure it’s my flavor, but I love the willingness to think different”. The community seems to agree too as there is a lot of activity and discussion regarding Haml. Hampton jokes about the growing community:
“Reading the Haml forums is a weird experience. Its like reading a love letter to a technology.”
Hampton feels that 20 minutes is all you’ll need to fall in love with the simplicity of Haml. However, Grigsby disagrees, he thinks that 2 minutes is all it takes.
For more information read Grigsby’s introduction, and check out the Haml website.
/filters:no_upscale()/sponsorship/topic/2c0d72d2-1768-47c2-8f5b-24f3ef0ae0e0/QconNYrsb-1679560094156.png)
/articles/eda-mediator/en/smallimage/event-driven-architecture-with-mediator-topology-small-1685547200315.jpg)
/articles/azure-functions-quarkus/en/smallimage/azure-functions-on-quarkus-3-1685542580748.jpg)
/minibooks/architecture-2023/en/smallimage/logo-1685600892155.jpg){kind=logo}
/presentations/lyft-cd-benefits-challenges/en/smallimage/tom-wanielista-small-1685002834068.jpg)
/presentations/green-software-growth/en/smallimage/Marco-Valtas-small-1685609473905.jpg)
/articles/test-automation-ci-cd/en/smallimage/effective-test-automation-approaches-for-modern-CI-CD-pipelines-small-1685355310638.jpg)
/articles/impact-machine-learning-climate/en/smallimage/minimising-the-impact-of-machine-learning-on-our-climate-small-1685091723283.jpg)
/articles/kafka-clusters-cloudflare/en/smallimage/tales-of-Kafka-at-Cloudflare-small-1684768928637.jpg)
/presentations/refactoring-cleaning-code/en/smallimage/kent-beck-small-1684908700538.jpg)
/presentations/devsusops/en/smallimage/adrian-cockcroft-small-1684908390875.jpg)
Community comments
Hmm...
by Werner Schuster,
Re: Hmm...
by Evgeny Zislis,
Re: Hmm...
by Werner Schuster,
Re: Hmm...
by Evgeny Zislis,
Re: Hmm...
by Peter Mergaerts,
i'm afraid ..
by Mo Li,
Re: i'm afraid ..
by Evgeny Zislis,
what is the process?
by Alex Popescu,
Re: what is the process?
by Evgeny Zislis,
Hmm...
by Werner Schuster,
Your message is awaiting moderation. Thank you for participating in the discussion.
I have to be honest, I still don't see the point. A 30% reduction of might seem nice, but then this comes at the price of significant whitespace (I spent too much time working on timestamping/signing code to like whitespace), a custom syntax, and custom semantics.
All this needs to be supported by tooling too.
If it was a 200 % reduction of code and also milked my cows, then I'd understand ... but for something like this, I'd rather go with a internal DSL solution like Markaby or Seaside's HTML building facilities.
Or is there something else I'm missing? (I'm not saying HAML is bad, just that I didn't have a light bulb moment yet).
i'm afraid ..
by Mo Li,
Your message is awaiting moderation. Thank you for participating in the discussion.
i'm afraid it won't work well to me. We have to take care of CSS, which will drive some changes on HTML code. I am good at CSS, but I can't write any pure HTML code (I mean the structure) before thinking about the CSS implementation, like naming.
Re: i'm afraid ..
by Evgeny Zislis,
Your message is awaiting moderation. Thank you for participating in the discussion.
You must not be afraid.
Since Haml actually comes with a little brother named Sass, which makes your CSS feel happy too.
And seriously, when you can refactor both your html and css with two little indentations or copy-pastes -- it makes all the difference.
I don't know the % that sass saves on your css, but if you wont take a look and give it a change -- you will never find out.
Re: Hmm...
by Evgeny Zislis,
Your message is awaiting moderation. Thank you for participating in the discussion.
Haml will not make your coffee, its true. But sincerely, after you try it - and you notice that you go "Wow!" and you jump from your chair several times, you will feel differently.
Thing is that this "forced indentation" is finding your typos and mistakes for you. Something that html/rhtml does not do. And the produced html is beautifully indented and readable right there in your fav. browser's view-source window.
It just makes you spot mistakes and move things around much more easily, because changing the indentation makes a difference. And getting used to it takes about 2-20 minutes, depends on who is counting.
Re: Hmm...
by Werner Schuster,
Your message is awaiting moderation. Thank you for participating in the discussion.
> And the produced html is beautifully indented and readable right there in
> your fav. browser's view-source window.
Well, I saw that argument too... but frankly, why would I care?
Sure, if my target audience was urban geeks, age 15-25, who browse the web with telnet, then yes: HTML indentation is useful. But otherwise, I don't care what the HTML looks like.
The other issue is maintenance... the old question of whether Ruby or Rails code can be maintained 5 years in the future, when the original developer has long moved to his private island near Dubai... wouldn't the maintenance developer prefer to look at something that has a spec and that more than 30 people have heard of?
Oh well... maybe a Rails-style screencast (with a lot of "whoops"es) is necessary for HAML so even folks like me get it.
Re: Hmm...
by Evgeny Zislis,
Your message is awaiting moderation. Thank you for participating in the discussion.
So you don't want to have your html indented... but perhaps you would like your html compressed to save bandwidth, like the front page of google. How would you do something like that with rhtml?
About maintainability - I maintain quite a bit of my own rhtml written less than a year ago, and what I have been doing for the last couple of months is mostly using the backspace and del keys, just before I "Save as..." haml.
BTW, thats has been the best bug fixer I had for my rhtml for these last couple of months. I managed to fix quite a few things this way. Quite frankly, I doubt that I would have discovered most of it even years from now by just looking at rhtml ...
So maintainability of rhtml itself is quite arguable. IMHO Haml helps with maintainability, and being so easy to learn -- I am sure the maintenance developer will manage.
When there is any problem, bug, question, suggestion, or anything else - the Haml mailing list is the place to go. I would like to thank Nathan Weizenbaum and Hampton Catlin for answering almost immediately and helpfully to all queries I have ever asked or suggested over there. And they usually do it in a matter of minutes.
To get Haml, all you need to do is take some extremely ugly rhtml that you are afraid of - and use the backspace and delete keys of your keyboard ... well, and space bar, for the indentation. If its extremely hairy - it may take you up to 20 minutes or more -- but in the end you will see the essence of the 'view' (of MVC fame) shine through the thick bracket and 'div' tag camouflage.
That must bring a shining smile of success on anyone's face.
Re: Hmm...
by Peter Mergaerts,
Your message is awaiting moderation. Thank you for participating in the discussion.
When I started using Rails 10 months ago I liked almost everything about it, save for the rhtml part. Checking all those closing tags to get your html right. But since it's standard you bend and use it anyway. Then, I came across #haml. My first thought was: 'Indentation is important, where the TextMate/Eclipse plugin which helps draw the lines in the editor.' Seriously, I converted the loginscreen to #haml, was cursing a bit at the not so very clear error messages haml threw back then (these are now very verbose and clear), but when you look at the converted view code, you immediately grasp the complete overview of the page, even if it's a complex page with lots of nested code and partials. The next day I switched all rhtml pages to #haml and use it for all the views. When maintaining a set of views in an older project they get converted to #haml first.
So, if you use Rails, give it a serious try at least once.
what is the process?
by Alex Popescu,
Your message is awaiting moderation. Thank you for participating in the discussion.
It looks interesting, but I am wondering what is the process of designing/updating new pages. Probably in same cases where the developers are the ones creating the pages this will work, but what about the cases where designers are involved? They are using their tools and they are giving you html and css. Are you gonna need to rewrite it from scratch everytime?
./alex
--
.w( the_mindstorm )p.
________________________
Alexandru Popescu
Senior Software Eng.
InfoQ TechLead&CoFounder
Re: what is the process?
by Evgeny Zislis,
Your message is awaiting moderation. Thank you for participating in the discussion.
There is a small utility called html2haml. But frankly, good designers that know a little bit html will find it much easier to work with haml than most of their existing "IDE" html writers. And by doing that, everyone will be happier and less puzzled when looking at the results.