And I think that's a reasonable opinion to have, since we already have a language (JavaScript) that can do conditionals, loops, and functions much more naturally than some styling system on steroids. And of course you can use any other language to produce the markup in the first place. Do we really need to turn the styling system into yet another Turing-complete scripting language?

I'm waiting for the day when I can forget about both Sass and LESS, and just use vanilla CSS4, CSS5, or whatever comes next. Variables are coming soon. Proper nesting is probably next on the list. I may be wrong here, but I suspect that using LESS (which is closer to vanilla CSS) in the meantime will make it easier for me to transition to CSS4/5 later, because I won't be spoiled by all those fancy features that will probably never get implemented in vanilla CSS4/5.

I don't think that these features are really in the styling system - Sass is essentially a tool that makes it easier to generate CSS, rather than being a replacement for CSS. And the output of that is a static, declarative stylesheet with no logic. I don't consider that any different from (say) a set of macros.

I won't be spoiled by all those fancy features that will probably never get implemented in vanilla CSS4/5.

I absolutely love Sass, especially when combined with Compass. I agree that those features will never be implemented in CSS, and they are IMO not appropriate features for a declarative styling language. But it's not like Sass is going away any time soon, and it has the massive benefit of being an effortless transition to CSS if you want to do that in the future. But in the meantime, I see absolutely no legitimate reason to avoid using it.

It's not about Turing completeness. It's mostly about DRY and flexibility.

For instance, imagine using theme prefixes or conditionals.

For-loops are fantastic for grid systems.

The point of this article isn't "should you use a pre-processor" - it's pointing to the fact that if you use one, SASS has more natural structures for common tasks like for-loops or conditionals, both of which are indeed useful.

Exactly why would a "real" language make more sense than that?

Define your styling framework in scss, use it from multiple backends.

A common case is to share between a static site generator for a public site, and an app framework for the app, which may well be written in different languages.

I agree that programmatic things should be done with programming. I also think that for those who are coming from CSS, the barriers are lower with something that has the shape of CSS.

And, the other part of this argument for pre-processors is that they "work." If I were to approach most junior front-end devs with a given programming language versus SASS to generate their CSS, most of them would pick SASS simply because of syntactic familiarity. Not a particularly compelling reason methodologically speaking, but the natural shift does make it a reasonably easy transition from purely declarative to pseudo-dynamic.

The purist in me agrees, but the practical implementation says these things are valuable.

I think the terminology doesn't convey the right idea. A SASS function is more akin to a macro that saves you a lot of typing and gives flexibility in writing CSS. At the end the result is plain styling instructions, no more no less, and thus it has no functional similarity with a js function parsed, loaded and executed at runtime.

And yes, preprocessing doesn't belong to the styling system, and it doesn't need to, as you use it a level above (it would be meta-styling I guess).

There's a really big difference between a Turing complete preprocessor and a Turing complete styling system.

There are clear advantages to having the client receive styling information in a non-Turing complete format, the major ones being performance and avoiding non-halting programs. A Turing complete preprocessed language does not remove those advantages, because preprocessing happens only once.

In fact, I would argue that it increases those advantages. As you mentioned, we already have JavaScript, which can be (and often is) used to manipulate styles. If you want to avoid a Turing complete styling system, then you want a Turing complete preprocessor. Better to have the arbitrarily complex program running once on the server side via SASS, than to have it running in the browser on every page load, via JavaScript.

I was reading this thinking, "Why would I need /that much/ complexity in the stylesheet? I get variables and some other niceties... perhaps I'm not thinking complex enough with HTML5 video games and whatnot.

    @mixin background-img($image, $width: image-width($image)/2, $height: image-height($image)/2 ) {
      display: block;
      background-image: image-url($image);
      background-size: $width $height;
      width: $width;
      height: $height;
    }

As far as I know, something like this isn't possible in LESS.

http://compass-style.org/reference/compass/helpers/image-dim...

So, perhaps I misspoke: Sass's power is in its ability to tie it's functions to arbitrary Ruby code, which can then access and manipulate files.

Thanks for the tip.

LESS can be run in the browser (usually only for development, I hope) and in the server side.

LESS resembles vanilla CSS more.

(Purely personal) I like LESS' syntax better. So there.

Also, why should I ever use a loop in a style sheet? I've never ever felt the need. And I don't think I will in the near future.

Also, I dislike these articles which imply that one should switch to a technology because it's objectively better. It's never the case.

SCSS syntax or SASS?

While those are nice features, they are not game breakers. Yes, I would say to somebody that is new to pick up Sass. However, to change all our system from LESS to Sass based only on those features? I'll stay with LESS for a while.

However, I don't need any of these extra features. It's good to know that they are there if I ever start to feel the constraints of LESS though.

1) It is good to have choice.

2) LESS is simpler and closer to the thing it compiles into: CSS. When dealing with complicated abstraction layers, it can be useful to not veer too far away from the target.

There's a place for both. I find the entire genre of "Everybody must use the tool I'm using" blog posts to be a bit strange.

I can see that as being less popular than something closer to what most people know.

Furthermore, for me it has two main drawbacks: Firstly, the dependency on Ruby. Not everyone works on a mac where it's easy to install. Sass/Compass plugins are cool (I love the syntax of Singularity) but they add a whole new dependency chain, fiddling around with Bundler and gemfiles. I don't want to install all this crap! Combined with the awesome (and necessary) nodejs tools grunt & bower there's almost more config files then project files in my working dir...

This ESPECIALLY becomes a problem now we are moving towards Continuous Integration. Try installing Ruby on one of the cloud sollutions for CI out there. The only one that supports it is Travis. But you only want to use that for open source projects, which we don't do. The business plans are ridiculous.

The second drawback is SPEED: Sass is insanely slow compared to the javascript driven (nodejs) Less. Even for small projects I have to wait 10-20 seconds after a save before autoreload kicks in. Less is near instant.

The basic features of Less and Sass are similar. LessHat will give you most of the mixins you need. Combined with the SPEED and PORTABILITY of Less, this makes me want to move from Sass to Less.

Original source http://www.zingdesign.com/less-vs-sass-its-time-to-switch-to...

I plan on doing this for our team pretty soon.

Now, there is libsass; a C/C++ implementation of the Sass compiler which brings Sass compilation up to speed with other preprocessors.

My feeling is that the community has always regarded Sass as the better preprocessor, but easy of use and compilation speed matter held it back. But, as front-end build tools have become more accessible, and Sass getting up to speed with libsass (and dropping the Ruby dependency), I think it is becoming easier for projects like Bootstrap to start embracing Sass.

If I wanted to improve CSS I'd remove things and tidy up the existing mess... but that my opinion.

My opinion is also that things like LESS and SASS only exist because CSS is in a poor state to start with... preprocessing in all of its forms is generally an evil to avoid if at all possible, and one that good design can utterly avoid - at least conceptually (if not in implementation where it might be beneficial).

I especially don't want to add to the towering stack of unreliable and buggy technology I need to fight with to work on the web... :/

http://compass-style.org

I can't make websites anymore without it.

Do loops belong in your style? NO.

Do loops belong in the thing that generates your style? YES.

One advantage of using Less is the existence of (php) libs so you can compile on the server. If you're developing for WordPress users for example you can expose some variables (ie colour scheme) and recompile stylesheets with minimal fuss.

https://github.com/twbs/bootstrap-sass

(edit: tell that the port is official, i.e. by the maintainers of bootstrap)

Has anybody tested out Myth yet? http://www.myth.io/