ansaurus

Question

What would be some reasons to decide against HAML/SASS?

Answer 1

+7 A:

If you're using Rails, yes. Go for it. Some issues you will hit, though, will be that any other developer brought onto the team later will have to learn it, as well. If you're already working with a big Rails crowd, that's fine, but HAML/SASS may confuse a designer who's worked with pure HTML/CSS for years.

If you're not using Rails, though, a good HAML/SASS integrated system is hard to come by. There are a few out there, but I imagine they're not as well-supported or as far along with the spec.

But, yeah. HAML/SASS is definitely worth it. The only real issue you'll hit is that it's not yet standard.

As for mix-n-match, HAML and SASS are so similar in style that I'd say go for both, but it, again, comes down to personal preference. Try using both for a day, and if you don't like one of them, switch back. There's no technological issue about it, so do what you prefer.

Matchu 2010-02-07 20:14:41

it just seems to me that there is almost no learning curve to switch, so would having someone who's worked with pure HTML/CSS learn HAML/SASS be an issue?

GiH 2010-02-07 20:19:24

It really shouldn't be, but there are stubborn people out there who can't learn new methods. It was a stretch of a con, but it was the only one I could really think of. HAML/SASS is pretty darn awesome and, if it ends up being a personal fit for you (or your team), just go with it. It doesn't have many inherent flaws in the system itself, so people seem like they would be the only real barrier.

Matchu 2010-02-07 20:27:09

You cant get much simpler that HTML/CSS. Do you really think that "The only real issue" to running a ruby process to add end tags for you based on the tab delimination of your source file is that "it's not yet standard" ?

2010-02-07 21:10:08

@jib: Ayup. It's not clear if you're talking about adding a bit of extra load on the existing Rails process, or using `--watch` to convert in a more static environment. In the first case, HAML performance nowadays is now extremely close to ERB, so the effect on the end-user is negligible. In the second, there is absolutely no performance hit for the end-user, so of *course* I'll take my preferred markup style. I'm not sure what sort of other ill effects of HAML you're talking about, but performance definitely isn't one of them. Is it just principle or something?

Matchu 2010-02-07 22:34:57

Answer 2

+1 A:

why is this..

%p
  hello world

better than this..?

<p>hello world</p>

clue.. If you aren't doing ruby, it isn't. Unfortunately adding closing tags and braces isn't really the most challenging aspect of making webpages, so most professionals wouldn't really care. Use whichever you prefer.

2010-02-07 20:17:56

It's most definitely a personal decision, but the OP has already established that he likes HAML/SASS better. "It's not really all that better" isn't a valid con in this case.

Matchu 2010-02-07 20:28:06

It might cure angle bracket based RSI.

Rich Bradshaw 2010-02-07 20:31:47

How is reassuring the OP to go with his preference not valid?

2010-02-07 21:03:41

If you don't want to use Haml, fine, you're right that it's a personal choice. But you clearly haven't put enough thought to give an informed answer. I'll tell you why that snippet might be better: Because you chose the case where Haml gives the least benefit, and it still saves code. The less crap I have to wade through when I'm editing your pages, the better. It's not about "adding closing tags" being hard — it's about them taking up space in your document with no benefit. Haml's benefits are meant to be in readability.

Chuck 2010-02-07 22:24:22

Less code? Yes. Increased dependency? Yes. Swings, roundabouts? Yes.

2010-02-07 22:30:11

@chuck I've thought about it. I thought about it just the other day when i was at my workplace writing haml, that thing i do all day everyday, as my occupation. What i thought was.. "Ironically, the structure of this document would be clearer and more readable in html". Really, really, should all html be written in haml, because there are no downsides to haml? Honestly?

2010-02-07 22:53:55

If you had thought about it, I think you should have expressed your actual opinion about why Haml is less readable rather than acting like its raison d'etre is to save people the trouble of typing close tags. My problem with your answer isn't that it's negative toward Haml — my problem is that the answer totally misrepresents the reasons someone might use Haml.

Chuck 2010-02-07 23:24:00

Answer 3

+5 A:

There are lots of tools for working with HTML and CSS. The syntax isn't pretty, but the improvements from HAML and SASS don't seem that dramatic to me, and for many they're not worth the trouble. Of course, for those developing web application with widely differing frameworks (differing from Rails that is) it's even harder to find a reason to go to the pain of integrating something so foreign. (Example: care to explain what I'd have to do to integrate SASS into my Java/Stripes/JSP environment? :-)

Pointy 2010-02-07 20:29:17

The differences from HTML to HAML are basically cosmetic, you're right about that. However, SASS provides functionality that doesn't exist in CSS such as variables, mixins, arithmetic (for dimensions and colors), loops, and more. It really puts CSS on a whole different level. The new version 3 of Sass actually supports two syntax modes, and they're now promoting the SCSS syntax (a CSS-lookalike with curly braces) because people were getting hung up on the whitespace-aware SASS syntax and not realizing there's more to it than just a different syntax they might not like.

Andrew Vit 2010-06-20 10:58:48

Sass doesn't have to "integrate" into your environment. It only generates static CSS files, so you can use any method to invoke it. I generally always use compass (a library of style functions) on top of sass, which provides a `compass watch` command for automatically compiling sass files on save. [voted you -1 since you already got 6(!), and it's not that well informed... no hard feelings. :-) ]

Andrew Vit 2010-06-20 11:03:01

@Andrew by "integrate" I mostly meant "integrate into the build process", which I think such a tool would have to, in some way. Either it becomes part of the application build, or else it becomes a *separate* build. Either way, it has to "integrate" into the way I do my work. An "automatic compile" tool, for example, would be completely useless in the sort of build environment I'm used to (and that I prefer). The question is asking for opinions, so downvoting my opinion based on *your* clearly incomplete understanding of *my* situation seems ridiculous.

Pointy 2010-06-20 12:31:49

Answer 4

+5 A:

I've been on volunteer projects where HAML's syntax curve (syntactical whitespace, the automatic generation of tags etc) has been seen as a barrier: one more thing for a programmer new to the project to learn.

Personally, I think SASS is worth it, but I'm up in the air about HAML: having debugged HAML templates before it seems like the typing you don't have to do with HAML is overcome by the time you spend debugging why there's an error on your templates. This could be a (HAML) newbie's perspective though.

RyanWilcox 2010-02-07 20:33:53

I agree, I found HAML much harder to work in than plain HTML. Every time there is a bug in the browser, you have to map the HTML output back to the original HAML ... I just don't understand what the benefit is meant to be. New syntax, intolerable and ill-thought whitespace, extra debugging layer.

Toby Hede 2010-02-08 02:11:45

Answer 5

+1 A:

HAML/SASS may indeed be awesome to use, but they do introduce dependencies both technical and knowledge-oriented. This may not be an issue if your dev and prod environments are controlled and predictable enough, with newbies receiving enough training (or being vetted for subject knowledge on the way into the organization) to hit the ground running, but all of that is overhead to be acknowledged.

Eric Hill 2010-02-07 20:36:05

Answer 6

+2 A:

I'm inclined to agree with the question; it is easy to switch, the syntax isn't that complicated, and it does make things cleaner and more efficient. It also makes it harder to unwittingly generate invalid HTML.

I also think the learning curve is shallow enough that a programmer that can't handle it, is probably a programmer you are better off without on your team. That might sound harsh, but I believe it.

The only cons I can see would be if you are developing in ASP.NET or something where retrofitting Haml and Sass would be a pain, is way unexpected for anyone else used to the platform, and possible a chore to maintain in a production environment. On Rails though, go for it.

calmh 2010-02-07 20:43:41

Answer 7

+2 A:

I don't think that using HAML ever adds much benefit to a project.

SASS, on the other hand, effectively introduces variables and computations and other really useful features that save you time and effort in the long run on larger projects.

Using SASS is incredibly smart with any project that's larger than just a simple one-page form.

Chris Papadopoulos 2010-02-07 21:19:07

Answer 8

+1 A:

I tried using SASS but found that editing CSS using MacRabitt's CSSEdit (Mac Only) was way easier and more efficient for the way I work. I'm a very visual person and like to have a live preview when making changes to style sheets and didn't feel like investing a ton of time into something I wasn't having a problem with.

Beerlington 2010-02-07 22:14:08

Answer 9

A:

From a developer's perspective, Haml and Sass absolutely rock. However: from a designer's perspective, Haml and Sass might not be readable. It really depends on who is on your team.

If it's a bunch of developers and/or designers who aren't afraid to learn a DSL, then absolutely go for it.

If you have a mixed team where designers toss their CSS and HTML work to developers who translate that to Haml/Sass, sure.

If you have a design team that passes work to the developers AND the work flows back to the designers, you may not want to use this because the designers might not be able to use their tools to edit the files.

If you have a small team where marketing and business people need to edit the web pages and they only know HTML and a light bit of CSS, then you probably shouldn't use Haml/Sass.

However you can't really make a blanket statement here. Consider that at least with Rails you can mix the template types in your views. So, some of your templates can be plain HTML stuck in .erb files, and other pages are .haml files. You can have partials be of one type inserted into templates of another. (I think mixing types is probably a bad practice, but if you just need to "get the job done" then it's an option.)

Amy 2010-02-09 06:43:22

thanks, I've actually updated my question in light of your answer. How easy is it to switch back from HAML to HTML?

GiH 2010-02-09 16:48:25

You mean just get the HTML back out? Haml eventually ends up as HTML. (Your web browser has no idea what Haml is.)You could just render the page and then do a View Source in your browser and copy out what you needed. Or, in Rails, just render your template back to a string and save it to a file...If you're thinking of converting Haml -> Erb, hm, I don't know of any utilities offhand.

Amy 2010-02-10 16:25:09

Answer 10

+1 A:

One thing most people don't realize is that HAML sucks for content. It's great for structural markup, but don't try and push it too far. (You can mix & match HTML in your HAML file, too!)

Sass is absolutely indispensable, especially in the long run. It's not just about writing the stylesheets when you have it all in your head, but about maintaining them down the road. The new Sass3 takes the syntax question out of the equation: you can take your pick if you prefer the curly-bracey SCSS syntax.

Andrew Vit 2010-06-20 11:11:50

ansaurus

tags:

views:

answers:

What would be some reasons to decide against HAML/SASS?

related questions