I Heart SASS, But HAML, I'm Just Not That In To You(intridea.com)
intridea.com
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
15 comments
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.
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.
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.
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
"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.
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.
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:
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"))))))
body.loading { font-size: 12px; color: #fff; }
body.loading ul#sidenav li { blah: blah; }
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.
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.
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.
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.
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.
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.
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.
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:
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")))))
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.
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.
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.
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.
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.
You can convert HAML/SASS 1:1 anytime, so the "maintenance headaches" argument is not a valid one.
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.
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.
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.
> 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).
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).
By far, anti-Haml people seem to be more likely to proselytize than pro-Haml people.
Actually I wrote the article after attending the Red Dirt Ruby Conference and getting HAML evangelism left and right. :)
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.
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.
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. ;)
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. ;)
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.
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.
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.
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.
The reason Haml has the reputation of being weak at inline markup is because people want to do:
%p Hello,
%strong World
!
%p Hello, <strong>World</strong>!
I believe the most elegant solution is still
:markdown
Hello, **World**!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.
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.
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)
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)
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.
I also wanted more specifics though, I felt like this was a fine opinion piece but lacked any specific world lessons.
Conditional nesting is pretty easy using the "capture" method:
- conditionallyNested = capture do
.foo
.bar
baz
- if f(x)
.wrapper
= conditionallyNested
- else
= conditionallyNested
<% condition = f(x) %>
<% if condition %><div class="wrapper><% end %>
<div class="foo"
<div class="bar">
baz
</div>
</div>
<% if condition %></div><% end %>
= wrap_if f(x), :class => 'wrapper' do
.foo
.bar
baz
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.
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.
Closing tags are a hassle. That's reason enough for me.
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?
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?
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.
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.
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.
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.