I Heart SASS, But HAML, I'm Just Not That In To You

http://intridea.com/2011/5/4/i-heart-sass-but-haml-im-just-not-that-in-to-you

by renaebair • 15 years ago

24 42 15 years ago

_pius2• 15 years ago

By far, anti-Haml people seem to be more likely to proselytize than pro-Haml people.

mbleigh4• 15 years ago

Actually I wrote the article after attending the Red Dirt Ruby Conference and getting HAML evangelism left and right. :)

_pius2• 15 years ago

Fair enough. :)

That said, there's a difference in tone between saying, "Haml is awesome, I love it, check it out!" (enthusiastic) and "Erb sucks, don't use it." (harsh)

Most Haml people I've seen/read seem to adopt the former tone, while most anti-Haml people adopt the latter tone. YMMV of course.

shawnee_• 15 years ago

The complete opposite is true for me. HTML should be as clean and simplistic as possible, which is why it makes sense to me write HAML instead of HTML for .rb

CSS, however, is the fun where the true art of front-end design happens, so I think it's fun to play with a forgiving syntax.

masklinn• 15 years ago

> CSS, however, is the fun where the true art of front-end design happens, so I think it's fun to play with a forgiving syntax.

It's fun to play with a forgiving syntax, but it's no fun saying the same thing 50 times.

That's why I like LessCSS (more than SASS anyway): LessCSS just feels like future CSS, a better CSS. Not something different, not something complex (it adds 4 basic features to CSS), it's a simple mechanical transformation and the output is easy to predict (I'm not fond of the &-combinator, but that's about the only criticism I have for it).

moe• 15 years ago

There are some things that HAML simply won't do

Like what?

I have never bumped into anything haml wouldn't let me do. Does the author know that he can embed raw HTML with :plain and friends? (which, btw, are very rarely needed in practice)

wwarneck2• 15 years ago

The most common problem is conditional nesting, like with wrapper divs. In addition to :plain there is also :erb. I think the poster was implying that occasionally you'll need to structure code in a way that is not optimal (work arounds) to do something that requires no special work in erb.

I also wanted more specifics though, I felt like this was a fine opinion piece but lacked any specific world lessons.

snprbob86• 15 years ago

Conditional nesting is pretty easy using the "capture" method:

  - conditionallyNested = capture do
    .foo
      .bar
        baz
  - if f(x)
    .wrapper
      = conditionallyNested
  - else
    = conditionallyNested

Personally, I prefer this over duplicating the condition:

  <% condition = f(x) %>
  <% if condition %><div class="wrapper><% end %>
    <div class="foo"
      <div class="bar">
        baz
      </div>
    </div>
  <% if condition %></div><% end %>

However, you can trivially abstract my first example out into a helper and result in code looking like this:

  = wrap_if f(x), :class => 'wrapper' do
    .foo
      .bar
        baz

Much nicer looking, in my opinion. I don't consider this a workaround at all.

freedrull• 15 years ago

Is it just me or is this the 100th "SASS rules but HAML drools" article this week? This one doesn't even point out the biggest weakness of HAML, that it is terrible at inline markup.

wwarneck2• 15 years ago

An interesting post, but I felt you stopped short of any specifics that would help sway someone on the fence or without an "educated" opinion already.

While I prefer HAML to ERB, I understand that occasionally wrapper divs can be a hassle in HAML. I assume this is what you're alluding to in Breadth and Scope, but maybe there is more?

The point of this post may not have been to add clarity for people not familiar or already opinionated, but if it was, the more specifics the more helpful it'd be for someone like me.

bherms• 15 years ago

I disagree... I love them both. Everyone knows HAML has a weakness - inline markup - but it's meant more for templates than anything. I typically make my templates with HAML and use erb for the more advanced views. That being said, I rarely ever need to resort to erb.

bradly2• 15 years ago

The reason Haml has the reputation of being weak at inline markup is because people want to do:

  %p Hello, 
    %strong World
    !

When what Haml recommends is:

  %p Hello, <strong>World</strong>!

If it seems like you are fighting Haml, check the docs and the mailing list. There is a good chance there is another way to solve the problem.

drdaeman2• 15 years ago

I believe the most elegant solution is still

    :markdown
      Hello, **World**!

Confusion• 15 years ago

That is not the reason why it has the reputation of being weak at inline markup: this is the exact reason why people consider it to be weak at inline markup: it doesn't support inline markup at all.

However, I fail to see why that's a problem. HAML is an abstraction that explicitly acknowledged it is leaky. It just doesn't support inline markup; you'll have to fallback to html to get, just like you have to fallback to assembler from C or JNI from Java to be able to do certain things. I say that's a good thing. Draw a clear line.

dogas• 15 years ago

I'm just not buying it. Look at his example erb code, compared to haml. Which would you rather be typing day in and day out?

In terms of learnability, it takes 15 minutes to learn 95% of the haml featureset. So you spend 15 minutes, then presto, less repetitive stress injuries from hitting the shift key all the time when creating view templates. AND it's much easier to read, and it forces correct indentation. That's just a whole lot of win.

Also, haml and sass are not mutually exclusive, nor are they a pair. They are 2 different tools that work with 2 different things.

mbleigh4• 15 years ago

I may not have been very clear about this, but that's exactly my point. I've gotten grief for liking SASS but not using HAML and I think that the two solve two entirely different problems and lumping them together has never made sense. They simply happened to start out in the same gem.

myronmarston• 15 years ago

ERB is a useful tool to have in your toolbox. It's very flexible. It's capable of templating _any_ kind of text file, but since it's capable for all of them, it excels at none of them.

HTML imposes this very strict structure: tags must be closed properly. Sure, browsers can handle tag soup to varying degrees, but it's a very bad idea to have your app render invalid markup. Humans are terrible at ensuring all tags are closed properly. Computers are great at it.

When templating HTML, I prefer to use a tool the was specifically designed for HTML. HAML auto-closes tags for you. Erector (http://erector.rubyforge.org/index.html) is probably my favorite, as it auto-closes tags, allows you to write your views in pure ruby, brings the power of OOP to your views, and gives you a far more clean, testable view layer. Want to test your view? Simple: instantiate the view class with the necessary arguments, render it, and make assertions about the output.

bradly2• 15 years ago

It should really come down to which is going to be the easiest to maintain and have's coding styling is different. If you aren't prone to forgetting a closing tag, then it might not make such a difference.

rimantas2• 15 years ago

Sass offers solutions for some CSS shortcomings: lack of variables, mixins, terse nesting and like. And easy modularization as a bonus. You can have all that with regular CSS syntax (SCSS). HAML offers… well, just different syntax. So I see very good reasons for using SASS and see no reasons to use HAML. Or maybe that's just 15 years I've been writing HTML.

cheald• 15 years ago

I resisted Haml for a long time for much the same reason. I then ended up using it for XML views (rather than builder, which is rather slow) and was rapidly hooked. I don't think I would ever go back to writing raw (X|HT)ML given the choice.

grimen6• 15 years ago

Don't forget the people than need to clean up the typos from the non-syntetic-sugar - aka "keep it native" - guys, and pay the salaries for work that takes 3 times longer just becuase of some weird principles. The best thing with this is that it's optional, and if you get into a project with HAML/SASS you can convert 1:1 back and forth so...not a big deal.

rimantas2• 15 years ago

  Don't forget the people than need to clean up the typos
  from the non-syntetic-sugar - aka "keep it native" - guys

HAML has some features which prevent from making typos when typing code? Interesting. Anyway, I am not sure what typos are you talking about. Syntax-highlighting + validation is good enough combination for me to avoid typos. Honestly, never had that problem.

  and pay the salaries for work that takes 3 times longer

Why would it take three times longer? I do produce my HTML manually, but that does not mean I type every single character in the code by hand. Snippets, Zen-coding/Sparkup, autocomplete, etc.—all this allows to produce HTML fast, efficiently and avoid syntax errors.

fleitz• 15 years ago

I tend to agree with the author but come to a different conclusion, yes HAML is just pure style, but I like being stylish. It's not what you say but how you say it.

JonnieCache• 15 years ago

Closing tags are a hassle. That's reason enough for me.

huherto• 15 years ago

Pardon, the OT stupid question, but I have had this doubt for some time.

I have only superficial knowledge of SASS and JQuery, but it seem to me that can you do the same things with both?

SASS manipulates the CSS in a precompilation step. JQuery mainipulates the CSS at runtime.

Are there any considerations when choosing between both?

Bootvis• 15 years ago

Why do something at runtime when you can do it at 'compile'-time? Plus, it's much easier to seperate the presentation layer from the rest if you use CSS/SASS and about as powerful.

hopeless3• 15 years ago

They both abstract the programmer from what's actually being produced and I can't help thinking that this is a bad thing.

I'm currently maintaining/developing on a 10yo Java project which contains a mix of JSP pages and ECS^-generated HTML in servlets. Which one is easier to maintain? The JSP pages by a mile because there is a direct correspondence between the source and the output. The ECS-generated HTML is totally obscured within the Java code.

So while HAML and SASS (to a lesser extent due to the similar syntax) abstract us programmer from the limitations of HTML & CSS, I can't help feeling that they will create huge maintenance headaches for our future-selves. Will anyone actually know HAML in 5-10years time? So, suck it up and use ERB and keep your abstractions as close to Earth as possible.

^ Apache ECS (now EOL'd) lets you build the HTML tree as nested Java objects.

mbleigh4• 15 years ago

Another reason I love SASS: since it compiles directly into CSS, if we all forget how to read SASS we can always just start modifying the resultant CSS instead. HAML on the other hand does not compile into ERB.

hopeless3• 15 years ago

Great point! I'd forgotten that about SASS.

fbuilesv• 15 years ago

The phrase "abstract the programmer from what's actually being produced and I can't help thinking that this is a bad thing" sounds weird given the fact that you're using Java, a technology that also abstracts some of the underlying capabilities of the C/ASM system you're using.

Abstraction itself is not bad thing. Knowing that a lot of the technologies that we're using today will be obsolete in 10 years is not a good enough reason to stop trying new things.

hopeless3• 15 years ago

We don't write 1's and 0's. Programming is an abstraction. But we still need to pick and choose what abstractions we use and where. Do the benefits of that abstraction outweigh the problems it creates? In the case of HAML (and ECS, grrr...) I don't think it does.

grimen6• 15 years ago

You can convert HAML/SASS 1:1 anytime, so the "maintenance headaches" argument is not a valid one.

edw4• 15 years ago

This post is a great example of what I dislike about Ruby culture, making a big deal out of pretty simple stuff. At least the article didn't mention DSLs.

This SASS thing, it seems interesting… I'm a Scheme programmer. I'd like something like it. After about forty-five minutes of hacking, I came up with this:

https://gist.github.com/956113

It lets you write code like this:

    (make-css
     '(("body.loading"
        (font-size "12px")
        (color "#fff")
        (" ul#sidenav"
         (" li"
          (blah "blah"))))))

And generates output like this:

    body.loading { font-size: 12px; color: #fff; }
    body.loading ul#sidenav li { blah: blah; }

I agree with the guy's point though: SASS is different from HAML in that it actually does something conceptually useful, viz. it introduces a scope-like concept to CSS.

drdaeman2• 15 years ago

I'd disagree - HAML adds syntax sugar. While it can be considered bad (there are some very valid criticisms), it certainly can't be considered conceptually useless.

edw4• 15 years ago

I know nearly nothing about HAML, but if it's "just" syntactic sugar, then I'll stand by my statement that it's conceptually useless. Or maybe conceptually barren. HAML can very well be useful without introducing any new concepts. It's obviously more concise which i can see justifying its existence if for no other reason.

edw4• 15 years ago

Hey guys, I was thinking about my implementation of Sass (apparently, it's not supposed to be in all caps) and came to the conclusion that it's not simple enough. I wrote a version that obviates the need for a bunch of the parentheses. You can check it out here:

https://gist.github.com/957123

The example above can now be written thusly:

    (make-css
     '(("body.loading"
        font-size "12px"
        color "#fff"
        (" ul#sidenav"
         (" li"
          blah "blah")))))

Have a nice day!

I Heart SASS, But HAML, I'm Just Not That In To You

Related Stories