Sass, LESS or vanilla CSS

[i-like-robots]

Discussions about whether to use a pre-processor or vanilla CSS and if the former whether or not animations could or should be implemented as mixins or via an extension.

[enjikaka]

I suggest Sass. It'll be compiled to vanilla CSS in the end anyway. Sass will make the dev a bit more comfortable.

[paulirish]

We're not authoring in vanilla CSS. In the world of transitions + transforms it will be a total mess.

Sass (scss specifically) is what the consensus seems to be. Less and Stylus ports are welcome to track the reference implementation but I do not see it as a core goal of the project.

We'll distribute in both SCSS and a compiled CSS.

[chriscoyier]

The big advantage to Sass is that this could essentially big a big ol' mixin library or library of %placeholder classes. That way you just @include effeckt-modal or whatever on your .modal and you're good. What makes it to production is only the bits you actually use.

And also obviously: helping with prefixing and just overall code writing comfort.

[AaronLayton]

+1 for SASS + Bourbon

[enjikaka]

I think using Bourbon in Sass is a good idea, as @chriscoyier suggested in the previous thread.

[round]

+1 for SASS

[i-like-robots]

I agree that Sass is the most powerful tool, especially the %placeholder as @chriscoyier mentioned.

I think any further dependencies or integrations with other tools, E.G. Bourbon, could be too opinionated and alienate potential users.

[joeybaker]

One thing worth thinking about with prefixing: autoprefixer via grunt-autoprefixer is a pretty nifty way to handle the problem. That way builds get automatically updated to remove deprecated prefixes.

[i-like-robots]

Are we not only now dealing with the -webkit- prefix for keyframed animations and transitions? http://caniuse.com/#feat=css-animation

Perhaps extra tools are a bit overkill for one extra prefix?

[kshmir]

I vote for sass as long as its still simple to use with pure css. Which I
think is a project goal

[joeybaker]

@i-like-robots nearly. IE9 still requires a prefix for transforms http://caniuse.com/#search=transform

[sindresorhus]

Sass + Autoprefixer

This would let us use node-sass (fast) in the future.

[KittyGiraudel]

It looks like everybody's okay with Sass.

[AaronLayton]

SASS it is

Discussion for autoprefixer, Compass or Bourbon #3

[darsain]

The most popular preprocessor (overall) seems to be Less (probably due to Bootstrap). The most powerful (but unfortunately least popular) seems to be Stylus (since a few days ago Stylus also does placeholders via a $placeholder syntax, works the same as in Sass). Sass seems to be in the middle in both popularity and features.

So don't we have a bigger problem in here? I personally hate it when every other CSS framework/library is in a different preprocessor, creating a diversified community and leaving me annoyed. On the other hand, none can expect developers to maintain multiple versions for each preprocessor out there.

I rarely see someone address this problem. Probably because there is no obvious hammer for this nail.

[chriscoyier]

@darsain The only hard numbers I've seen is the data we compiled at CodePen which has Sass kinda crushing LESS. http://blog.codepen.io/2013/04/08/statistics-on-preprocessor-usage/

[darsain]

@chriscoyier that wasn't my point, really. But I'm glad if that's the case as Less really lacks in features.

I'm just surprised that not more people are pushing Stylus, which has such an amazing syntax embracing simplicity, super set of features, and god damn transparent mixins! How can anyone realize what transparent mixins are, and go for a preprocessor that doesn't have them... or the awesome Stylus syntax.

Anyway, back to the point: CSS preprocessors have diversified community, creating an environment where getting any popular framework/library in your preprocessor of choice is a major pain in the ass - i.e. impossible.

Is there any incentive to address this, or should we continue carry on with fingers in our ears shouting "lalalalala" as we do with package managers? :)

This web environment is really an interesting one.

[jbeja]

@darsain

Pro for Stylus:

1. Stylus have a nice syntax (so do Sass)
2. Have nice features (so do Sass),
3. It can be easy installed (so do Sass).

Pro Sass

1. Can do most what Stylus do (some better done in Stylus and some better done in Sass)
2. Have more extension and projects supporting it by defualt (yeoman, compass, bournon, inuit.css, guard and so on).
3. Is desinger friendly since you can use either .saas extesion or .scss (not every body wants to right in an python like syntax and is not always about power but flexibility).

Subjective toughts

1. Most designer and front-end devs use OSX (I don't, i use Ubuntu) and it comes with ruby by default, the only thing that they have to do is to type in the terminal $gem install sass
2. You are always open and free to write your own port of this projects.
3. I feel you, i actualy don't like Bootstrap and i think that something like Inuit.css is far better and more powerful. But as you see, like all things in life, it is more about context and preference.

[grayghostvisuals]

We like Sass and that's loud and clear obviously. I suggest the following to Stylus and LESS people (chirp, chirp)…
Let those who want the other ports (Stylus, LESS) just follow along and PR where needed. If those other ports (Stylus, LESS) want it bad enough they will allow for their survival.

[mgcrea]

Why would you ever pick a ruby based-stack (guard+sass) when the web is powered by javascript with awesome tools specifically designed for it (grunt/bower/yeoman+less/stylus). I can get the sass choice, but I'm a bit clue-less about the guard vs. grunt thing.

[jbeja]

@mgcrea yeoman support sass by default and to be honest guard is more simple than grunt in my experience, for the simpliest workflow i can type $ guard init sass livereload maybe config the Guardfile and i am ready to go.

[sethburtonhall]

Sass FTW

[OpherV]

I'm up for Sass as well.