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.

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.

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

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

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

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

  ul :id => 'foo'
    li 'hello'
    li :class => 'bar' 'world'
  end

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

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

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

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

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.

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

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.

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

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.

So perhaps html is "easier" to "read", 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.

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?

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.

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.

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.

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.

I love that statement.

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?

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.

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

N.B. It's Haml and Sass, not HAML and SASS.

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

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.

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.

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.

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.