

I Heart SASS, But HAML, I'm Just Not That In To You - renaebair
http://intridea.com/2011/5/4/i-heart-sass-but-haml-im-just-not-that-in-to-you

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

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

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

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

~~~
rimantas

      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.

~~~
grimen
"Honestly, never had that problem."

Most common problem with manually generated XML/HTML is broken tags (not
closed correctly).

"Why would it take three times longer?"

The number 3 is just picked by me based on my own experience - I finish views
way faster than the ones I've worked with, with best-pratice semantics. If you
write valid semantic HTML as fast as me with no tool you are just very good,
but you don't represent the majority.

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

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

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

~~~
grimen
Would be cool to benchmark this. Me with HAML/SASS vs. you guys with HTML/CSS.
Points given for implmentation time and output validity and semantic quality.
A few years ago Ruby was syntetic sugar, later Rails, later HAML/SASS. Give me
a break.

~~~
edw
1\. It was the Java people who pooh-poohed Rails. The rest of us just got to
work cloning it, sans any issues we had with it, in our favorite languages. I
haven't seriously programmed in Java for almost ten years.

2\. _Syntactic_ sugar isn't just hand-waving; it has a reasonably-concrete
definition. And it's generally considered acceptable if it delivers enough
convenience (The concept of _enough_ , you will find, is highly subjective.)

3\. No one in this exchange has busted on the utility of SASS, so I don't
understand why you'd deny anyone a SASS-like tool in a cage match nerd bake-
off. For that matter, no one has busted on the practical _utility_ of HAML in
this exchange, just on the absence of new concepts i.e. powers of abstraction.

~~~
grimen
1\. The pointer was "many developers was hating on it" - I didn't say
everytime it is the same people. You kow that, this bullet was just waste of
characters really.

2\. Reference me the official definition. Another point that didn't add
anything to the discussion.

3\. SASS been heavily hatred on in the past, Google it. Practical utility:
Inofficially 80% of Rails/Sinatra developers use HAML - why? Because it makes
people productive.

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

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

~~~
hopeless
Great point! I'd forgotten that about SASS.

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

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

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

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

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

~~~
mbleigh
I think you're right about the tone but there's a simple explanation for it:
ERB is the default. Everyone has used it and no one (+/- a couple people) is
already using HAML and needs someone to come along and say "Hey, have you
heard about this awesome thing called ERB? You can just write HTML and inline
your code right there!"

I may have missed my mark in the writing because my point isn't to say that
HAML sucks; my point is to say that there are logical reasons to decide NOT to
use HAML just as there are logical reasons TO use HAML. What I was tired of is
the assumption that HAML is simply universally superior and anyone who doesn't
use it only does so because they don't "understand" HAML.

We have the facts and we're saying ERB. ;)

~~~
grimen
No matter if ERB is a default chosen by someone (that might not be 100% right
- in fact we all know no human do): People who like ERB views should like PHP
views as well. No more commments needed here except that ERB is the part of
Rails that cause most frustration.

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

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

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

~~~
drdaeman
I believe the most elegant solution is still

    
    
        :markdown
          Hello, **World**!

------
moe
_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)

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

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

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

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

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

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

