I’ve been window shopping the CSS preprocessor world the last week or so. Sass seems to be everyone’s new bicycle but it hasn’t won me over and here’s why:
- It’s a new syntax that I don’t want to learn or support. I have an awesome job where we often hire new people and (hopefully) acquire new clients and the last thing I want is the added friction of having to teach (and sell) a new styling syntax.
- It’s a terrible idea for a CSS preprocessor to be whitespace sensitive. Don’t get me wrong, I love whitespace sensitive languages. It’s why I use Python and think YAML is a Zen like experience, however, I’m one of those nut jobs that puts properties on a single line. I actually do this for readability. I can scan a document of single line CSS like nobodies business. Sass looks pretty on the tutorial pages restricted to five lines but when 622 lines of CSS balloons to 3,000+ my insides begin to hurt and so does my scroll wheel. A lot of zealots (I kid again) are going to say, “But they’re going to support native CSS syntax (http://nex-3.com/posts/83-sass-and-less) like LessCSS!” That’s great, why? They should have either started with this or not done it at all. Good luck supporting two syntaxes.
- Why the frak do I need control directives in CSS? If I’m using a @for loop to generate styles I’m doing something very wrong. CSS is not a programming language, it’s a style language and the preprocessor community should keep that in mind.
My rants aside, we can learn a lot from Sass. Variables, mixins, and nested rules are a great idea and lead to cleaner code. Why can’t we spice up CSS and make a preprocessor that just does a few things incredibly well? LessCSS has been a great example of this, but what about a preprocessor that compiles CSS3 down to CSS2? With any luck the preprocessor community has the potential to greatly influence the CSS language by showing the W3C how people want to use it. This is a better direction than creating unnecessary friction by devising a completely new syntax for everyone to adopt.