HAML: the unforgivable sin | Hacker News Reader

HAML: the unforgivable sin

opensoul.org

36 pointsbkeepers44 comments

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.

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.

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.

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.

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.

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".

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?

HAML indention also prevents common coding mistakes like poorly placed closing tags

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).

FYI, you can wrap any line of Ruby at a comma, provided there is one.

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...

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

HAML completely eliminates the "Oops, where did I forget to close that div?" problem. It also punishes you a bit for putting too much business logic in your templates, which pushes you towards well-factored views with your business logic in helpers, and your actual markup in the templates, resulting in cleaner and easier-to-maintain templates. From a debugging standpoint, HAML can output perfectly-indented HTML for your whole document, so templating needs don't end up screwing up your indentation, resulting in extremely readable output if you need it.

I think it's completely disingenuous to rag on HAML while praising Coffeescript. They both provide the same effective result, but for two different products. They eliminate the annoying, slow, cumbersome parts of working in their counterparts.

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

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.

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.

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.

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.

Well I'm your case this makes sense. Speaking for SASS and LESS here, you know you can get a few other apps that'll compile and help you debug your SCSS styles. There's CodeKit, LESS.app, and now Crunch. These tools take you to the line in your SCSS file that's causing issues instead of referring to the compiled CSS.

I mean, hear what you mean but I think the level of annoyance or love for these tools depends on your workflow. Personally, I use LESS along with CodeKit (I used to use LESS.app) and I usually don't have those problems. The times that I do run into a line number reference problem I'm usually able to find the offending code quite easily as the line in my abstraction language file (LESS, Coffeescript, whatever) is usually only a few lines lower than what the debugger tells me. In addition, if the debugging tools give me just a short snippet of the offending code then I can pretty easily remember where it is regardless of how large the file is.

In the end though I think this is all about a person's workflow. Some workflows are better suited to these abstraction languages and their compilers/debuggers than others. Personal preference, I guess, is what it comes down to.

> 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.

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.

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.

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.

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.

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?

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.

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.

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.

> 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.

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

I love that statement.

"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?

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.

> 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.

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.

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.

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.

I felt the same as you, until I actually decided I'd try it in a project just as an experiment. I will now never go back. Looking at it, "meh"; actually using it, "awesome!".

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.

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.

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.

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.

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.

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.

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.

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

Reply on news.ycombinator.com