With Rails 3 around the corner, choosing a templating framework (and testing frameworks and ORMs) will be a decision Rails developers can make on even ground. ERb and Haml will be equally supported in places such as generators.
So how do we choose?
Looks
A lot of people think Haml is great-looking.
It’s true. Haml looks very clean in the examples. I think the template code in Boston.rb is quite beautiful:
#events
.ribbon
.row
.crud
%p= link_to 'New event', new_event_path
%h2 Recurring Events
- @recurring_events.each do |event|
.quarter>
%p.date
%
= event.date.to_s(:fancy_date)
%span= event.date.to_s(:time)
%h3= link_to h(event.title), event
%p= event.cached_description_html
Very readable. All those noisy <% end %>s and closing HTML tags are gone.
ERb is beautiful, too
ERb, I imagine you must take all this Haml attention personally. Don’t feel
down. Your <body> is a wonderland.
For example, when I want to go vertical when I want to, such as in this Formtastic example from one of our apps:
<%= form.input :logo,
:input_html => { :class => "upload_field",
:style => "width: 340px;" },
:label => 'Logo',
:size => '30' %>
Or this example of a typical Clearance sign up form:
Sign In
<div id="signin">
<% semantic_form_for :session, :url => session_path do |form| %>
<% form.inputs do %>
<%= form.input :email %>
<%= form.input :password, :as => :password %>
<%= form.input :remember_me, :as => :boolean, :required => false %>
<% end %>
<% form.buttons do %>
<%= form.commit_button "Sign In" %>
<% end %>
<% end %>
</div>
This style is in line with a few of thoughtbot’s internal coding standards:
- indent two spaces regardless of HTML or ERb tags
- align hash keys and hash rockets when going vertical
The first standard is exactly the same as Haml but the second is intentionally awkward in Haml using the pipe character. Hamlistas will say: move it into a helper.
Good point. Then you can go vertical in normal Ruby code.
Is beauty only skin deep
The argument for either framework on looks alone is unfortunately steeped in personal preference. Let’s go deeper.
One fewer thing to learn
I worked on a Rails project with a PHP developer. I wanted her to learn Ruby, testing with Shoulda and Factory Bot, git, REST… Haml was a lower priority. ERb and immediately felt familiar to her.
Lesson: ERb’s interpolated tags are familiar for ASP, PHP, and JSP developers.
Yet the same one fewer thing to learn argument can be made for Haml. Look at
that Boston.rb example again. Now see how our JQuery code deals with .crud
inside #events:
jQuery(document).ready(function($) {
$('#events, #jobs, #projects, #presentations, #companies, #apps, #show, #edit').hover(
function() {
$(this).find('.crud').show();
},
function() {
$(this).find('.crud').hide();
}
);
});
Lesson: Haml’s re-use of CSS selectors are familiar for CSS and Javascript developers.
Active development
Haml is under active development. For example, the Haml team recently responded to newer competitor, Less by altering Sass to become a superset of CSS. New ideas and features are being shared and improved upon.
ERb isn’t capturing the imaginations of the open source community right now, but is also older and stable. It is working software that you can wrap around yourself like a security blanket.
The only thing that matters: institutional standardization
thoughtbot standardized on ERb. Hoptoad was on Haml for a long time but we converted it to Erb.
Hashrocket announced they standardized on Haml.
Both are examples of companies that work on a lot of apps. I believe the gains from institutional standardization, such as code re-use and developers mastering a common set of tools, outweigh any other pro or con and likely leads to cost savings.
Visit our Open Source page to learn more about our team’s contributions.
