I'll jump in, because I spent six months developing a web app using Sass. It's a nightmare to maintain on any sort of complicated, big project. For various reasons... I previously blogged about it here: http://fecklessmind.com/2009/01/28/fuck-sass/
Ultimately, yes, you can use whatever the hell you want. But if you're a front-end developer, if you care about your webiste scaling to millions of users, if you care about providing best experience even to dial-up users or users of old PCs / Macs, then you're going to spend the time optimizing everything you can. Sass goes against that and creates bloat. Fine for back-end developers who just want the pain of working with CSS to be over, maybe, but not for front-end developers.
I doubt you'll ever return to Sass, but I wanted you to know that we did take away that there's not really a good reason to force 1 style per line. We're going to add support for semi-colon delimited styles on the same line. No one has ever complained about it on the mailing list before...
Where's the bloat? As mentioned a couple comments up, you can have Sass render the css into a single line CSS file for production. And you render it once, and cache it forever. Same overhead as a css file, maybe even less, because it's auto-minified for you...
Sass doesn't make you bloat your css, but it does make it easier if you rely heavily on mixins. That said, if you've got a website of any complexity then you're using gzip compression for your static assets, and the compressed file sizes are pretty much identical. In terms of rendering performance, I've not seen any comparisons but anecdotally, I've not noticed any slowdown.
Bloat doesn't necessarily mean code size. It could also mean redundant selectors, code that is difficult to maintain, and plethora of other things. As mentioned previously, I'm a front-end web developer, I spend majority of my time coding graphically-heavy designs in CSS and maintaining them, as well as doing JavaScript. In my experience, Sass has been a nightmare.
So far, the only people that I've heard praise Sass are back-end programmers, rather than full-on front-end developers.
It's seems great for developpers. The minus part of generated code and all those frameworks is of course that it doesn't go in the direction of "view source" readability. Is css becoming an "assembly" for style inside browsers?
This problem could be solved with better editors. You could switch between "programmatic mode" (with all variables and fancy stuff) and "view source mode" (with variable values and plain CSS in general) with one keystroke.
You could also have semi-programmatic modes that show some programmatic features and "expand" others. Also it would be possible to look at the plain CSS but have values coming from the same variable in a distinct color.
We should get more creative with multiple views of the same document in the editing department.
Sass actually takes pains to make the source code it outputs readable. This isn't always entirely possible, since by its nature expressing something in Sass can take significantly less code than the CSS counterpart and properly organizing the expanded code automatically is hard. But there are several output styles designed to be readable, and it's possible to add comments that are rendered as CSS comments.
I am in process of redoing my webapp (merb based) with compass. I think the approach is right on. I hope it gains enough momentum to be a great "programmer oriented" CSS framework.
I've been using Sass for awhile now and absolutely love it. I had never heard of Compass, and as a recent BluePrint adopter, I really appreciate this article.
Its times like these I wish I could redistribute earlier 'upmod mistakes' to this posting.
I have been using Sass (and its companion Haml) for quite a while now and I highly recommend it. Working with normal HTML and CSS seems like such a chore now.
It looks similar to the CSS we generate from s-expressions in Lisp (even has : before keywords). We're in the process of dumping it altogether, though, and doing everything in Javascript.
Misleading title, by the way. Even if you generate CSS from (slightly) higher-level source, you're still using CSS for layout.
I know the title was tongue in cheek to attract the yc crowd.
One thing though is that once you use compass with the blueprint framework implemented in sass it allows you to easily generate css in situations where you would have used a table instead for layout.
Is there anything that dumps css all together and just manipulates the dom directly using Javascript.
In other words, build your site by instantiating components as you would if you were building a windows or flash application. I think that would be my preferred way of working.
For example: if I wanted a heading I could write a new class derived from a standard library, set a few properties to define its colour and font, perhaps some properties that define how it moves in relation to other entities.
You could even build a proper style hierarchy.
I've always felt the html / css / javascript stack was kind of clumsy and would love to just work in one environment.
I've never likes css and the very fact that things like Sass and Compass exist suggest to me its not really a very good way of defining an applications style.
Actually as much as I hate CSS, from trying to implement the same subsystem of an application using flash and then reimplementing it in javascript + CSS I came to appreciate the flexibility of CSS when you want to adapt your widget to both mobile phones and computers....
You might want to look at http://cappuccino.org/ for a javascript library doing what you describe (disclaimer: also I've planned for some time to take a look at it, I haven't got around to it yet)
I wrote something like this a while ago and just got reamed by all the CSS koolaid drinkers.
But unlike Sass it doesn't abandon the cascade, and things look a lot simplier, at least to me. I guess because its in LUA it wasn't cool enough.
It did get the "one of the best of the month" at smashing magazine, whatever that means.
Writing massive stylesheets made me write moonfall, and after I did that, I found that its easier just to keep your css simple. And then I never needed it.
2. tweak pixel-positions via Firebug and instant preview
3. write final positions into .css file
Firebug nicely display the line number of the css rule to tweak. This isn't possible with something like Sass, so i assume it would slow me down.
This instant preview tweaking with Firebug is even more important with legacy CSS to find the position where a certain value is set. I can't think of a way to do that with Sass.
CSS can do most of those n columns liquid layout or other complex design that people decide to use tables for. It's not a question of being able to do it or not in CSS, it's a question of how easy or hard it is to do it. And Compass makes it a great deal easier.
OK, I understand using it when it easier. But there are many things that tables can do that CSS can not do - at all (especially in a cross browser compatible way, but also just regular).
Ultimately, yes, you can use whatever the hell you want. But if you're a front-end developer, if you care about your webiste scaling to millions of users, if you care about providing best experience even to dial-up users or users of old PCs / Macs, then you're going to spend the time optimizing everything you can. Sass goes against that and creates bloat. Fine for back-end developers who just want the pain of working with CSS to be over, maybe, but not for front-end developers.
Haml on the other hand is great.