Haml Sucks for Content | Hacker News Reader

Haml Sucks for Content

chriseppstein.github.com

67 pointschriseppstein33 comments

terrible title, this post actually explains how to use Haml the plugin to generate all sorts of content using its existing features like filters properly. The confusion is that "Haml" refers to Haml the plug-in as well as Haml the syntax for generating HTML. The syntax is not ideal for content, and that's why it supports things like inline HTML and markdown filters, just as the outline explains.

The title is in the reddit linkbait genre that is becoming increasingly common on HN.

Chris Eppstein isn't writing Reddit linkbait. He's the author of Compass, which shrunk my huge Rails app's templating code by at least 30% and massively, epically improved our stylesheets, allowing us to standardize a sprawling rusty UI on a sane Blueprint grid inside of a week.

I don't like his title either, but he gets to write whatever he wants about Haml.

I stand corrected.

I disagree. I should be held to the same standards as everyone else.

On Twitter, someone gave an alternate explanation that I'll pass along without agreeing or disagreeing. They suggested the title was a honeytrap to get Haml haters to read the post and then be surreptitiously educated on why that argument against Haml is invalid.

Update... That was Chris' explanation!

I stand corrected.

Well I got caught in that honeytrap, so the title does work.

That's true, but it's also a play on words.

Haml (the syntax) sucks for content. This is a fact.

Haml (the project) provides ample facilities for working around the syntactic limitations.

The article could be replaced by the sentence: "Make sure you know about filters before using haml for content."

Filters aren't a "workaround," they are the part of the language for handling content.

http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#fi...

Just because they're officially supported, doesn't mean they aren't there to work around the syntax's obvious limitations. I've been tracking Haml's development for a very long time I the history of many of these features is a result of users' frustration with the syntax.

As an experienced and enthusiastic Haml user, I find that this matches my experience exactly. If you're a Haml-hater, please read this post.

the only thing it's really ideal for is software engineers writing their own HTML. in professional team environments in my experience designers always like to be able to at least dip in to HTML, and as "illogical" as this might seem to a programmer, they are never going to learn something like HAML - it's just too complex and programmery.

FTA:

Inline your HTML: That’s right. Just put some HTML into your Haml document. Don’t be afraid, it’ll be just fine.

And that's a red herring, because unless you keep a designer on staff, in real systems designer markup never hits the wires. Even pure HTML still gets broken up into templates and partials.

Software developers may not have to design their own HTML, but they sure as hell have to write it.

I'm half programmer, half Web developer. I'm great at both (I don't mind saying). Being from both worlds, I don't get the need for HAML. HTML is so easy as it is. From my point of view, any programmer who can't write HTML with proficiency is deficient somehow.

    Whereas
     HAML
      is
       not

Wow. You definitely are half a programmer! Burned!

HTML is a huge pain in the ass to write:

* It requires balancing tags

* It's verbose

* It is crudded up with syntax (</-="") and keywords

* It consistently runs right off the 80 column right margin

* It's an enormous pain to extend

* It's slow to read; for instance, try picking the plural version of a constantly-used class name out of tag soup

Haml isn't a shortcut to writing HTML. On the contrary, to use it well, you have to know HTML well. What Haml does is to solve the problems that make HTML a pain to use to express user interface in.

I guess I set myself up? You make some good points about why HTML is a pain in the ass. I'm just desensitized to it to the point that it doesn't bother me anymore. In fact, I didn't even think of the issues you brought up.

I was once like you.

What it took for me was writing a UI in Haml with very minimal, semantic markup and all the controls keyed in jQ off classes and IDs.

When you structure your HTML, CSS, and Javascript correctly, Haml is absolutely gorgeous. You're no longer writing in HTML: you're writing in a DSL designed to express user interface. For instance, a "save" button encoded in a DIV in Haml:

    .button#save

That's it.

Does Haml allow you to control how the actual markup is produced? Some browsers are dependent on a lack of whitespace between nodes in order to render properly without adding some extra padding (IE for instance). For me, the main issue is control over my markup. Exact and precise control, which is necessary.

Haml does allow for finer-grained control over whitespace, but even if that's not enough, when needed you can still "embed" plain-old html directly inside of your Haml files.

I guess I fail to see how html has any advantage over haml. The absolute worst case is that you're still writing html in 90+% of the cases (which you'd be doing anyway without haml), and in the best case, your markup becomes much more DRY and readable.

HTML has an advantage because that's what people know, particularly designers.

Some designers I've worked with are ok with haml, others steadfastly refuse because their workflow is so HTML-centric.

Tool support is a good reason to not use haml. I expect tool support will be there some day, but it's not really there yet. RubyMine has very nice haml support tho.

Well, I seem to always have formatting issues with haml, though probably because I haven't worked enough with haml yet to internalize the whitespace rules. No such issues with html of course. Not a huge advantage, but can make it annoying when you're first starting with haml.

You can use the alligator operators to trim surrounding and internal whitespace. E.g.

    .foo> This has no whitespace outside the foo div.
    .foo< This has no whitespace just inside the foo div.
    .foo>< This has no whitespace outside or inside.

http://haml-lang.com/docs/yardoc/file.HAML_REFERENCE.html#wh...

Incredible, they even thought of that. I guess Haml isn't so bad after all. Time to check it out.

Isn't that the wrong level of abstraction, though? An actual save button in my application looks like this in HTML:

    <button id="Save" name="Save" type="submit" class="positive" tabindex="10">
    <img src="/graphics/icons/save.png">Save Changes
    </button>

I'm not sure what that would like in Haml, but in a template language it might look something like this:

    <ctl:SaveButton />

I would think a DSL designed to express user interface would actually be a much higher abstraction. Haml is just 1-to-1 with HTML.

You can do it this way:

    .button#save{positive, style(:save), etc}

Where "positive", "style", and "etc" are functions returning Hash. I don't bother, and put most of that stuff in jQ.

The direct translation of that HTML to Haml is

    %button#Save.positive(name='Save' type='submit' tabindex='10')
      %img(src='/graphics/icons/save.png')
      Save Changes

That button in your example, of course, has a lot of attributes, more than most elements in a typical template. Also, if you are using it with Rails it'd be in a form block with a helper:

    = f.submit 'Save Changes', :class => 'positive'

which would generate an <input> that you'd then style with CSS (or Sass :-D)

Note that with Haml you can also write any sort of helpers you want, so you could have something as simple as

    = button

doing whatever you want it to.

Where it gets really interesting, however, is when you are dealing with full templates. The document structure is instantly apparent, most superfluous noise is gone, classes and ids are given top billing and templates are very short despite retaining all of the information.

> The document structure is instantly apparent, most superfluous noise is gone

Except that normally document structure is already apparent. Most people don't write HTML pages from top to bottom -- sites consist of a common header, footer, sidebars, etc. Common controls (such as buttons, date selectors, voting tools, etc) can hide most of the superfluous noise. What then remains is easy to follow. It seems like Haml is to HTML what assembler is to machine language -- it's merely a 1-to-1 translator. Which is great if you want to work at that level but it seems you could get more bang for your buck with a higher level tool.

The big disadvantage of Haml is that it isn't HTML. Now using any template engine takes you away from HTML, but hopefully you get some real value added. With Haml, it's the same structure with a better markup. I don't see what the big deal is.

"It requires balancing tags"

Only for tags that need an ending delimiter, unless you use XHTML. Check out the Google markup sometime. All the <li>, <td>, <tr>, and <img> tags are intentionally unbalanced - because they don't have to be, and balancing them just makes your website take longer to download.

http://dev.w3.org/html5/spec/Overview.html#syntax-tag-omissi...

"It consistently runs right off the 80 column right margin"

I've never had that problem. I also have no qualms about breaking lines between tag attributes.

"It's an enormous pain to extend"

HTML5 "data-" attributes make this a bit easier. Still room for improvement here, though.

A lot of the pain points in HTML are self-inflicted by developers who read some "best practices" on the web and then never question what they get out of those best practices.

I agree that the problems HAML creates for collaboration between programmers and designers - who, as you say will never learn HAML - is the key limitation of HAML - a limitation also discussed by James Britt in his excellent post on the topic: http://www.jamesbritt.com/2009/4/29/thoughts-on-haml.

Reply on news.ycombinator.com