LESS vs Sass? It’s time to switch to Sass | Hacker News Reader

LESS vs Sass? It’s time to switch to Sass

flippinawesome.org

50 pointsremotesynth52 comments

None of those features matter if you're of the opinion that conditionals, loops, and functions don't belong in the styling system.

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 think this is a bit short-sighted.

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.

It's not shortsighted at all. CSS is declarative because if its programmatic, you might as well generate it with a real language.

The same could probably be said of most of the HTML generators out there. HAML, in particular, has a lot of similarities.

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.

It's a superset of CSS language that provides an additional DSL that extends it in a number of ways that provide significant productivity and design benefits.

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

That might be the opposite of what you want if there's any chance you'll be working with a heterogenous web stack.

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.

None of those features matter if you're of the opinion that conditionals, loops, and functions don't belong in the styling system.

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.

Hear hear.

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.

> None of those features matter if you're of the opinion that conditionals, loops, and functions don't belong in the styling system.

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).

>Do we really need to turn the styling system into yet another Turing-complete scripting language?

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.

This article actually misses one of the best features of Sass: It can access and read files. Why is that important? So you can easily reference and use images. Here's a mixin I use constantly:

    @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;
    }

I can then do something like @include background-img("logo.appheader.png"); in my scss files with a retina-quality image. I don't have to think about image sizes, it just works.

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

Whoa, I had no idea. That's really useful for retina images. I recently switched to SASS because of foundation. But I often found myself looking up image widths for my retina mixins.

Thanks for the tip.

Sass + Compass + Foundation is a winning combo. Unfortunately my product is built on bootstrap (using bootstrap-sass at least), so migrating to Foundation would take quite a bit of work.

That's not a Sass feature, it's from Compass.

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

Yes, the image functions are from Compass, but the underlying mechanics of mapping Sass functions to Ruby code is purely Sass's domain.

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.

LESS plays nicer with languages other than Ruby (less dependencies).

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.

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

SCSS syntax or SASS?

:nth-child() could be considered a form of a loop, a bit restricted loop though. You're looping through a collection and altering certain items in the collection based on a criteria.

I don't know.

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.

I agree it's not really worth it to port LESS yet, but I would say that it's not worth it to write anything new with LESS.

If I was freelancing, I would indeed spin on a dime and change to SASS, but in an enterprise setting, we can't change all our structures to use LESS. Well, we could. But it takes some time, and time is money, right? I'm happy enough with LESS as it is.

Interesting article. It sounds like SASS is more feature rich than LESS.

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.

I disagree for two reasons.

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.

Less also has way more portability with its Javascript compiler.

Really? You'd never use that in production (I hope!) and libsass is available, so I'm not sure that's true.

I've always viewed Sass as the css equivalent to coffeescript. Less has always been about enhancing css, while Sass is about replacing it with something better. Thus, it's natural that Sass has more features, but they come at a price.

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.

Interesting - it looks like LESS takes a hint from functional languages, with recursion and guards, both of which I recognize from Erlang.

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

In my company we have been using Sass/Compass for about two years now. Sure it's very cool, feature rich etc. But afaik we use only a small part of the possibilities. We don't need them all, cause we know how to properly write CSS.

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.

Cached http://flippinawesome.org.nyud.net/2014/01/20/less-vs-sass-i...

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

thanks for the extra links (while the others aren't working)

I'm having problems with your cached version. However, using Google's cached text-only page works fine: http://webcache.googleusercontent.com/search?q=cache:flippin...

Site is back up. Sorry for the issues. Had to throw a ton of resources at it due to the traffic surge.

For those of you who already use Grunt (if you aren't using Grunt, you can probably get used to the Ruby cli for SASS), there is indeed a relatively easy way to compile SASS: https://github.com/gruntjs/grunt-contrib-sass

I plan on doing this for our team pretty soon.

Grunt only takes 10 minutes to set up (5 minutes to add it to package.json and copy a working gruntfile, another 5 to realise grunt-cli should also be in the list of dev dependencies).

I love sass because i can always use libsass to compile the code faster without the need to install ruby.

An important point that was left out of the article is that LESS had much faster compilation than Sass, which was probably the deciding factor for it's use in Bootstrap.

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.

Why do I need either?

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... :/

The single most convincing reason to use SASS is that it allows you to use the Compass Framework:

http://compass-style.org

I can't make websites anymore without it.

I really don't see the major win in compass. When I used sass I tried to use compass, but browser they didn't cover all the edge cases I had, so I basically rewrote its scope for a wider browser range with higher level constructs in like half a day. Its a nice to have but hardly the winning card.

Here is a real world example of where I agree. There are times where you want to generate specific CSS based on some variables or what not. Say breakpoints or a grid system or other things like that. In those cases, it is way simpler to write a loop to do that than do it by hand for the exact same reasons we use loops in programming where it makes sense.

Do loops belong in your style? NO.

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

Unless you're heavily into using Compass or Foundation I don't see any major reasons to favor it over Less as far as features go. Both are really powerful.

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.

I'm not going to set up ruby/gem which is a PITA on debian/ubuntu(especially if I need a newer version and keep them sane) just for the sake of SASS, sorry. unless that is, you have something like pip for python that I can install to a sandbox under my home directory _easily_, as easy as 'pip install sass', do we have one?

RVM takes three commands to set up. And I don't even know Ruby.

Suspect that most people use less because of one of a) bootstrap uses it, b) it's easy to run under node or c) you can just drop an existing CSS resource into less without modification. I suspect that even if SASS could address b) and c), a) would provide less with a large userbase.

You can drop an existing CSS resource into SCSS without modification.

Yeah, but... https://github.com/jlong/sass-bootstrap

Indeed, there is an official SASS port of bootstrap on the horizon:

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

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

I have a feeling that quite a lot of people use LESS because of Bootstrap. And it is my personal guess but looks like even Bootstrap is trying to move to Sass - https://github.com/twbs/bootstrap-sass.

I've used LESS and have been happy with it. It was so easy to get up and running, and most of the companies I've worked at use it instead of SASS.

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

A related article from the author of the less-rails rubygem: http://metaskills.net/2012/02/27/too-less-should-you-be-usin...

I'm actually happy that they didn't put a whole programming language in LESS, if I want that, I will use a real programming language, also having to install a ruby environment just or SASS is too much for me.

AFAIK the only existing conversion tool is no longer maintained. So if you've got an existing less project, you might have to stick with it for now...

Reply on news.ycombinator.com