Sass Language Design: Philosophy & Approach (opens in new tab)

I've been using haml and sass for a while now, and I have to say that once you start using them, it's hard to go back. Sure, the major upfront benefit is less typing involved. For sass, there's no longer the long-winded

#main #content .post .title h3

CSS associations that you have to manually type out (or copy paste) each time you want to declare a style for something. More importantly though is that it creates much more readability. I can go back to code that I wrote months ago and see exactly where a style that I need to change is located in sass, whereas in CSS I'll have to poke around a bit. The tab delimited hierarchies will be a godsend when first you use them.

The variable declarations can be nice as well, although I haven't used those to their fullest capacity yet. Even without them though, I'd still use sass. That's not to say it doesn't have downfalls. It is another level of abstraction that you have to deal with. If you're building a server that's hosting .sass files, you'll need a sass compiler - not something you necessarily want to think about on a deadline. Then again, you can always just compile them before you deploy your packages, but you have to remember to update the .sass files if you ever make any on-the-fly changes on the server. That can always be remedied though by having a dedicated stylesheet server, although I typically only use one of those for development. I have a blank haml/sass template that I use for styling front ends, and will direct any site I'm currently making, regardless of the language, to the stylesheets hosted by that project. Even if you don't think you'll use it, I'd still give it a shot if you haven't played with it already.