Cheating on ERB with HAML
Flash!! Zoom!!
!!!
%html
%head
%link{ :rel => "shortcut icon", :href => "/favicon.ico", :type => "image/x-icon"}/
%title= "Wallpaper Love Factory :: "+controller.controller_name.capitalize
= stylesheet_link_tag 'wallpaper'
%body
.header#header
= render :partial => 'layouts/header'
.menu#menu= render :partial => 'layouts/menu'
.content#content= yield
It’s so easy! Anyone can do it. HAML is sweeping the rails world like a wildfire of chicken, and everyone wants the biggest piece. I decided to try it last night on my new wallpaper site, and found that it’s extremely awesome to work with. As you can see above, I used it for my application.haml layout. Here’s a breakdown of wtf is going on up there:
- !!!: That pesky DOCTYPE crap line that everyone hates and googles all the time.
- %tag: You use % to denote a new tag, and close it with indentation, like Python.
- %link{:rel => “shortcut icon”}: All the tag attributes are just a ruby hash!
- = stylesheet_link_tag ‘wallpaper’: Use the = to evaluate Ruby and display it.
- .header: Makes a div with a class of ‘header’.
- .header#homie: Makes a div with a class of ‘header’ and an id of ‘homie’.
- .menu#menu= render :partial => ‘layouts/menu’: Should be obvious by now. Renders a partial within a div with class ‘menu’ and id ‘menu’.
I found that it’s ridiculously easy to write views now. But what about loops?
- @wallpapers.each do |w|
.image[w]
= w.name
# Makes:
<div class='wallpaper image' id='wallpaper_4'>
Manatee
</div>
Holy dog crap! You don’t even have to use end anymore! It’s all Python style!
Now, if you want to have even more fun, you can make self closing tags like img!:
%img{:src => 'your_face.jpg'}/
# Produces
<img src='your_face.jpg'/>
This is probably a bad example because the HAML is actually longer than the result, but who cares!!!
For more tricks and stuff, check out the HAML reference and tutorial.
Just now learning Rails. Today was my first time using HAML. Very nice. Also easy to install.
I looked at HAML a year ag, and looked again.
Don’t want to be a killjoy, but is it faster than erb? If not, why bother?
When you have a big site to run, its a no go. For smaller experimental sites, its probably worth it. Besides, its another language that my designer has to learn.
Ericson:
I’m more or less done with Rails, so I don’t have to do much erb anymore. After using HAML for a while on some fairly advanced sites, I found it to be a pain when a lot of logic needed to be done in the view.
Lately, I’ve become a fan of Django and its template language. If you work with a designer, I would definitely recommend using something like Liquid if you plan to stick with Rails.
I have never worked with a designer, and a good template language would be essential if I had to. Giving them erb would give them too much power, and HAML, as you’ve stated, doesn’t really give them anything over it other than quick and dirty speed with less customizability.
Thanks for the question, though!
@ericson: I’ve deployed numerous large sites and as far as performance is concerned, Haml has never been an issue. In fact, according to [these benchmarks](http://nex-3.com/posts/57-haml-benchmark-inaccuracies) it was never really that slow. If you’re that concerned with performance you should be using erubius rather than erb. The argument for Haml vs ERB is the same as the one for Ruby vs *insert "enterprise" framework here*. It’s not claiming to be the fastest, but the savings from legibility, structure, etc that manifest in less wasted developer hours out weigh the ~16% performance hit… a hit you only have to wear in the unlikely scenario that you’re not doing any caching.
@hank: It took me far too long to try it but I’m finally a complete convert, make sure you check out the ugly step-brother of Haml, Sass.
Performance-wise, the most recent Haml version is about even with ERB. It’s faster in some cases, slower in others, but on average it’s more or less the same.
About logic in the views, Hank is right, Haml doesn’t work well for that. That’s intentional: Haml is built on the philosophy that logic doesn’t belong in views, that it belongs in helpers and the controller. Making logic and large blocks of Ruby code awkward encourages users to find a better way of doing things in the first place.
And as for designers, I’ve heard it said that designers are often very fond of Haml because it’s so closely tied with CSS, which is what they really think in.
@ericson: I am the designer half of my team. Haml was ok to learn, because Sass is awesome. The ability to have variables makes it worth what little time it took to learn Haml. Just changed all the serif fonts on a website today by changing one word in the variable.
@Hank: logic in the view?? are you crazy??
.menu#menu= partial ‘layouts/menu’
Much nicer! https://github.com/jcnetdev/better_partials
I wrote it specifically for use with Haml (thought its just a wrapper around render helper so it works with any view framework.
Designers shouldn’t touch views. They should touch styles. They should touch unobtrusive javascripts. Views should be touched by programmers. Programmers who see markup as data, not as design. The naming layouts and views is bad.
Of course, most scaffolds and helpers suck in this regard.
A nicety of haml … a view spec like this matters:
describe ’site/content_page’ do
it "should render" do
‘render ’site/content_page’
response.should be_success
end
end
Now if anyone fools around with the haml markup on that template, that test will fail far more often than if it was written in erb.