12 ms·

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

24 points by renaebair 15y ago

_pius 15y ago
By far, anti-Haml people seem to be more likely to proselytize than pro-Haml people.
- mbleigh 15y ago
  Actually I wrote the article after attending the Red Dirt Ruby Conference and getting HAML evangelism left and right. :)
  - _pius 15y 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.
    - mbleigh 15y ago
      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 15y ago
        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.
shawnee_ 15y 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 15y 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 15y 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)
- wwarneck 15y 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 15y 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 15y 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.
wwarneck 15y 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 15y 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.
- bradly 15y 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.
  - drdaeman 15y ago
    I believe the most elegant solution is still :markdown Hello, **World**!
  - Confusion 15y 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 15y 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.
- mbleigh 15y 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 15y 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 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.
bradly 15y 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.
rimantas 15y 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 15y 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.
- grimen 15y 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.
  - rimantas 15y 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.
    - grimen 15y ago
      "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.
fleitz 15y 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 15y ago
Closing tags are a hassle. That's reason enough for me.
huherto 15y 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 15y 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.
hopeless 15y 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.
- mbleigh 15y 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.
  - hopeless 15y ago
    Great point! I'd forgotten that about SASS.
- fbuilesv 15y 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.
  - hopeless 15y 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.
edw 15y 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 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 15y 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.
  - edw 15y 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.
    - grimen 15y ago
      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 15y ago
        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.

24 points by renaebair 15y ago

_pius 15y ago

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

mbleigh 15y ago
Actually I wrote the article after attending the Red Dirt Ruby Conference and getting HAML evangelism left and right. :)
- _pius 15y 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.
  - mbleigh 15y ago
    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 15y ago
      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.

shawnee_ 15y 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 15y 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 15y 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)

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

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

bradly 15y 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.
- drdaeman 15y ago
  I believe the most elegant solution is still :markdown Hello, **World**!
- Confusion 15y 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 15y 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.

mbleigh 15y 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 15y 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 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.

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

rimantas 15y 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 15y 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.
grimen 15y 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.
- rimantas 15y 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.
  - grimen 15y ago
    "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.

fleitz 15y 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 15y ago

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

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

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

mbleigh 15y 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.
- hopeless 15y ago
  Great point! I'd forgotten that about SASS.
fbuilesv 15y 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.
- hopeless 15y 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.

edw 15y 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 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 15y 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.
- edw 15y 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.
  - grimen 15y ago
    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 15y ago
      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.