
HAML: the unforgivable sin - bkeepers
http://opensoul.org/blog/archives/2011/11/30/haml-the-unforgivable-sin/
======
cheald
I spend my days working concurrently on married Rails (with HAML) and PHP
(with...PHP templates) applications, and I will unequivocally say that the
HAML templates are cleaner, easier to read, easier to maintain, and easier to
develop on.

HAML put me off at first because I thought exactly as this guy did - "Why do I
need to learn an abstraction? It'll just slow me down. I know HTML well enough
already." Once I actually started using it, my opinion there flip-flopped
_insanely_ quickly. I guess I would say that if you find HAML too hard to
read, you haven't spent enough time reading it. Most any form of data
expression takes _some_ time to learn.

HAML makes me faster. A lot faster. Not having to track down where a closing
tag was omitted, never accidentally crossing tag scope, and being able to
trivially ascertain the selector path of a given bit of markup makes
templating _fast_. I do a lot of it "the old way" too, and...it's just not as
fun. It's frustrating, and slow, and it's not because I'm bad at it - I did it
for years before HAML - it's because if you take the time to learn it, HAML is
genuinely better.

Terseness is a feature. It's not just an abstraction for abstraction's sake -
removing boilerplate and clutter that isn't really needed to concisely express
an idea is a real, tangible, honest-to-god feature. It's why I sigh every time
I have to maintain a config file in XML rather than JSON or YAML or even just
good old INI format. It is _the_ primary selling point of Coffeescript. It's
why Java is the butt of so many jokes. It's why people write DSLs.

Maybe HAML isn't useful to you. That's fine. Whatever you're most productive
in, work in that. But it's just arrogant to proclaim from on high that HAML is
an "unforgivable sin" and that anyone using it is worthy of nothing but scorn
and contempt.

~~~
dlikhten
My love for haml was formed in about... 5 minutes. I took an existing template
(had some free time) and ported it to haml. After eliminating about 30% of the
typed characters/lines on that template, I realized how much less work it was
to create a haml template vs html. Less maintenance, less syntactic bloat, the
content just flowed. Mind you I have been writing HTML for 4 years now without
any problems.

I no longer had debates (do I add a <span> tag here because I really don't
f-ing feel like typing it) because it was trivial. It let me focus on content
rather than the html.

Also zero possibility of someone screwing up indentation thus causing a 100
line file to become completely unmaintainable. Which happens VERY often in
html unless the writer is disciplined to all hell.

Also: less characters + cleaner syntax = significantly easier to comprehend.

------
callahad
When writing JavaScript or CSS, I find it much easier to determine how to
select an element, since classes and IDs follow CSS (and thus jQuery, et al)
selector syntax.

To wit, I find it much easier to derive 'ul#foo .bar' from

    
    
      %ul#foo
        %li "Hello"
        %li.bar "World"
    

Than from

    
    
      <ul id="foo">
        <li>Hello</li>
        <li class="bar">World</li>
      </ul>
    

Being able to more confidently and accurately pick selectors out of markup is,
for me, a concrete win.

~~~
nwmcsween
Consider haml to erector:

    
    
      %ul#foo
        %li "Hello"
        %li.bar "World"
    
      ul :id => 'foo'
        li 'hello'
        li :class => 'bar' 'world'
      end
    

I personally don't like haml's use of seemingly arbitrary keywords. Coming
back to a project and having to reread documentation due to cryptic syntax
wastes time.

~~~
cheald
What arbitrary keywords? "." and "#" are the existing CSS selectors for
"class" and "ID", and I personally really like that I don't have to type them
out all the time.

------
mef
So HAML is bad because it is "purely an abstraction of syntax", but
CoffeeScript is good because it adds things that are "extremely cumbersome to
code by hand". I'd say the closing tags, quotes, attribute names, doctype
declarations, etc that HAML removes are just as "cumbersome".

~~~
michaelcampbell
You failed to quote the rest of his premise: "CoffeeScript guards against
common coding mistakes, like ensuring variables are properly declared within
lexical scope."

I don't use HAML so I don't know, but does it provide features like that?

~~~
bradleyland
In a manner of speaking. Some things are difficult to do in HAML, which happen
to be things you shouldn't be doing anyway.

For example, I don't know how to write multi-line Ruby code (with the
exception of function calls) in HAML. I wouldn't be surprised if there is a
way, but you can't just drop it in like you can with ERB. This means that if
you need multiple lines of Ruby, you move the code a more appropriate area
(model, helper, controller, etc).

~~~
Groxx
You do multi-line Ruby the same way you do multi-line javascript or css:

    
    
      :ruby
        # ruby code goes here
      :css
        body { of-css: styles; }
      :javascript
        alert('and JS here');
    

":something" defines a language filter in Haml, and it reads the whole
indented block through that filter, and sometimes wraps it in a tag (:css and
:javascript get free %style and %script tags). Also available are :plain,
:sass, :textile, :markdown, etc. [http://haml-
lang.com/docs/yardoc/file.HAML_REFERENCE.html#fi...](http://haml-
lang.com/docs/yardoc/file.HAML_REFERENCE.html#filters)

Or, if you're a bit masochistic, you can use the multiline character: "|"
[http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#mu...](http://haml-
lang.com/docs/yardoc/file.HAML_REFERENCE.html#multiline)

------
gommm
Personally I use HAML because of readability, I find that it's much easier to
parse and see exactly what is going on compared to html with all the
extraneous syntax...

Well, to each his own, and sometimes it's also a question of taste

~~~
bradleyland
I was thinking the same thing. When our team originally brought HAML to me, my
initial reaction was similar. There's not enough value here to justify
hitching the wagon to this (at the time) small project. Rather than react
immediately, I took a couple of hours and converted some ERB templates to
HAML. The end result was so much more readable, and because HAML uses document
structure for interpretation, far more consistent.

So, I'd take issue with the author on the following points:

* I find HAML _more_ readable than HTML

* I find that HAML also gets you better structure and consistency in your view files

That's enough for me.

------
lucisferre
Wow, there's no hyperbole in this title.

Come on, it took me less than a day to become familiar and comfortable with
HAML (on first glance I would have agreed with the readability criticism).

As for usefulness, it has several features I find really useful:

1\. Using CSS style syntax to define divs

2\. Inline ':markdown', ':textile', etc. for content

3\. Really convenient way to inline javascript also great for UJS

4\. A much cleaner looking syntax for using helpers and in-lining ruby

I will partially give into the author's claim that it does require you be a
bit more careful, the white space formatting bites me in the ass from time to
time. I occasionally run into bugs that are a bit confusing with code blocks
and helpers, however it isn't a big enough problem for me to want to switch
back to ERB.

------
eterps
I like HAML ( or even better SLIM <http://slim-lang.com> ) because it directly
represents what HTML ultimately results in; a DOM. SLIM and HAML have a
similar representation as to what you see in a DOM inspector.

------
stiff
There are some more serious issues with Haml, Sass etc. that I wonder aren't
brought up more frequently. One is simply tool support, in Firebug or Chrome
developer tools I see HTML/CSS/Javascript not Haml/Sass/CoffeeScript. As soon
as I start using any of those "add-on" languages, I cannot refer to the line
numbers Firebug gives me for the various CSS classes, nor to the line numbers
a JavaScript debugger gives me, in fact I have to debug something more or less
different to what I wrote. In the end I cannot just know
Haml/Sass/CoffeeScript, I have to know both HTML and HAML, both CSS and Sass,
both CoffeeScript and JavaScript and switch between those languages
frequently. Unless you have a very small / very simple codebase, I think this
makes things not simpler, but more complex.

~~~
callahad
> As soon as I start using any of those "add-on" languages, I cannot refer to
> the line numbers [...]

I can't say I disagree, but I don't think this is a serious impediment. Though
Sass and CoffeeScript have recently pushed this sort of referential opacity
into CSS and JavaScript, it's been an "issue" in HTML markup for decades: As
soon as you introduce any kind of templating or conditional logic, you're
handing the browser generated content that doesn't map directly to line
numbers of files on disk.

In that vein, how is Haml different from ERB or Jinja2? The latter may
superficially resemble HTML, but they _aren't_ HTML. An even stronger parallel
could be drawn from Less or Sass's scss syntax.

------
conanite
Conciseness is the major benefit of haml. As a given template in haml is
shorter than its equivalent in html or erb, then naturally each line requires
more attention to read, there's more information in it.

So perhaps html is "easier" to "read", but in html you're mostly reading
noise.

~~~
moe
_but in html you're mostly reading noise._

To quantify: In your typical web-templates that contain little actual content
you'll easily approach 50% noise.

Next time you re-arrange some HTML template, pay attention to the time you
spend searching, counting and re-ordering all those closing spans and divs.

That's why people like HAML - it actually saves time.

------
victorbstan
I use HAML, I disagree with the main point of the article. Not only that, this
is an opinion piece, offers no actual evidence of HAML being harder to
parse/read (which I find ridiculous) than HTML. My opinion piece? I love HAML,
would not go back to HTML by choice. How are you going validate this opinion?
Let's bring quality articles back to HN, no more FUD please.

~~~
billpatrianakos
Hell yes. TQuality has been lacking as of late. Maybe it's just that newbie
illusion PG has talked about or maybe it's real. I feel it's real but hope its
an illusion.

------
wmoxam
If HAML is an unforgivable sin I want to be a sinner.

Btw, HAML eliminates a class of errors (improper tag nesting) and I find it
much easier to read. To each his own, but I don't get why such an opinion
piece is front page on HN. Is this the new Proggit?

------
nimblegorilla
I don't trust the opinion of anyone who finds HAML "infinitely harder" to read
than regular html and erb. I felt totally comfortable with HAML after only a
couple days of using it.

In my opinion it boils down to a vi versus emacs style flamewar. I'm going to
use HAML, but if people are happy without HAML then more power to them.

------
brianhempel
Yah, I'm skeptical of any language whose job is simply to make writing another
language prettier. If the problems of the lower language leak through, then
you have to be fluent in two languages for a single problem.

To all would-be language designers out there: Are you aiming to fix a
perceived language deficiency or a problem-solving deficiency?

C, Perl, etc. are abstractions of the problem of programming, not the problem
of writing assembly.

In contrast, HAML is an abstraction of the problem of noisy HTML, not an
abstraction of the problem of page layout.

------
Stratego
Did I just see a syntactic tool derided for being only good at reducing and
enhancing syntax? From a Ruby developer?

It's all about expressive code. There's nothing of value in a closing tag.
Nothing. No information than cannot be carried with pithy indentation.

And as others explained well, Haml when used in conjunction with scripting
languages encourages the removal of controller and model logic from the view
layer.

It doesn't try to add anything else to HTML because what the hell would it
add? HTML doesn't have lexical scope issues to fix. I can't believe this
shoddy piece is blaming a simple tool for simply doing its simple but useful
task.

------
rdtsc
> But I feel it is infinitely harder to read.

I personally find it much easier to read. I don't usually read HTML code or
HAML. By looking at both, HAML is much cleaner and easier to understand.

------
SolarUpNote
"Typing is not my bottleneck in coding. Thinking is."

I love that statement.

------
mhd
_"I still have to think about tags, ids and classes while I’m writing HAML. It
simply provides a more concise syntax."_

So he wants macros, again proving Greenspun's tenth rule…

While I disagree that just having a better syntax isn't worth it all by
itself, considering that we're talking about the utterly verbose nightmare
that's SGML/XML, couldn't you do some of that with inline ruby, filters,
partials, helpers etc?

------
ascendant
I know it's popular to hate on HAML but we use it on a large Rails app and
love it. I guess I'm more surprised at the number of people that are desperate
to type as little javascript as possible but are fine with overly verbose
markup. I prefer terse markup and verbose logic, myself. There tends to be
more gremlins hiding in the logic.

~~~
nknight
> _people that are desperate to type as little javascript as possible_

You've completely missed one of the author's most critical points. Verbosity
isn't the problem. I actually hate CoffeeScript's syntax, but the language
clearly reduces the thought-load of dealing with JavaScript. HAML really does
nothing to reduce the thought-load of dealing with HTML, even if I might
prefer its syntax to HTML's.

------
PLejeck
I completely agree that HAML and similar things are nothing more than
syntactical sugar, and not all that good of sugar either. I personally use
Handlebars, a Mustache variant, and have found it to be extremely helpful for
cleaning up my templates without sugaring my syntax.

TL;DR - I got 99 problems but HTML syntax ain't one.

------
mhartl
I find Haml easy to parse visually and prefer it to HTML and ERb (except for
pages that are mostly static content—Haml sucks for those). The only reason I
don't use it in the _Rails Tutorial_ is that it's not quite standard enough.
Neither was Sass, though, until Rails 3.1 added it by default, and the next
edition of the book (due out soon) uses Sass throughout. Will Haml chart the
same course? Stay tuned.

N.B. It's _Haml_ and _Sass_ , not _HAML_ and _SASS_.

------
zmoazeni
I don't have anything against HAML, and actually think the syntax is alright.
Even gave it a spin some smaller codebases. But I have a hard time finding
reasons to switch to it. Until I find a compelling reason to use it, HTML
works fine for me.

Most arguments I see seem to primarily argue around ascetics. I'd welcome
anyone to post their thoughts to help me sway my position.

To the author's credit, I immediately recognize the benefits of SASS and
CoffeeScript.

~~~
roryokane
One way I have found HAML functionally useful is that it was easier to move
code around the page. There are fewer lines to move, so it’s easier to
remember exactly what you’re moving, and I don’t have to worry about
forgetting to move the closing tag. You do have to re-indent after you move
the lines, but you would do that anyway with plain HTML. I did a lot of moving
code around the page when I implemented Photoshop designs, and I was thankful
for that aspect of HAML.

I also used the embedded-Ruby feature to DRY-ly have variations on a page
prototype. I was able to switch between four different versions of the page by
changing just one variable at the top – I used case statements and a few Ruby
helpers on the page to enable the appropriate sections and CSS classes of that
version. That was for a static page not linked to any web framework – it was
nice to be able to use code without having to set up a huge framework. It
could have been messy mixing Ruby code with HTML in the same file, but since
this was just a small one-off page, it wasn’t a problem.

------
ludicast
HAML is great fun for me (so is Coffeekup). I'm assuming I'd love Slim/Jade as
well but havent had the time to try it out.

Some people might not like it but for me those abstractions are way useful.

I wonder, with HTML5's eventually assendancy, whether the #id and .class div
shortcuts will eventually be less sexy.

------
phamilton
I find HAML mostly just replaces Rails tag helpers.

instead of:

<%= tag "div", {:id => "city", :data => {:name => "Boise", :rating => "good"}}
%>

I can do

#city{:data => {:name => "Boise", :rating => "good"}}

Which is basically the same thing. All haml does is encourage using a
taghelper like syntax for everything.

------
kenamarit
I disagree, I think HAML is so much easier to read. It's easier to see nested
blocks and where everything lies. I even started nesting my html when I go
back to update old projects in order to look more like haml.

------
billpatrianakos
I think this is all about your workflow and a matter of personal preference.

The most profound piece of this post was the part where he mentioned that
typing was not his bottleneck but thinking is. That's so true and it's what we
should keep in mind when deciding to use one of these languages. Who cares
which one of the cool kids are using it. What matters is "does this reduce
mental strain while still achieving what I set to do with the same result I'd
get with normal (HTML, CSS, JS, whatever)"? If the answer is yes then get out
your compiler and start writing in HAML/CSS/LESS/SASS/SCSS/Coffescript.

------
funkah
I have never really used HAML so I can't comment on it specifically, but I
really agree with his point about typing not being the bottleneck. It's much
more important to me for code and markup to be readable than to make it easier
to write.

------
PLejeck
People seem to worry far too much about the extra 5 seconds they would spend
to write HTML versus HAML, when it introduces so many other problems.

First of all, there's WAI-ARIA. Try fitting that into HAML or Jade and
suddenly it gets a hell of a lot more complex, pretty much negating all
benefits.

Additionally, I find that people think too much of the DOM tree as a goal,
when it's merely the way the browsers "think" of the page.

HTML is for making formatted documents, not for creating some abstract tree
structure. Next thing you know, people will start representing HTML as a
flowchart. (P.S. - PLEASE FOR THE LOVE OF GOD DO NOT DO THIS!)

Additionally, I'll openly say I don't like CoffeeScript. But that's not
because of the features it adds, it's the syntax. This is also why I use LESS
instead of SASS or Stylus: it took CSS and built on it, it didn't try to
replace it entirely.

We're so far into abstractions today that any more will actually hurt us. Back
when C was abstracting Assembly, it was important to make big leaps.

Now we iterate. We take what's been done and reinvent it.

So in summation: Don't Reinvent The Wheel.

~~~
phamilton
HTML is for representing data. CSS is for formatting documents.

