SASS vs. LESS | Hacker News Reader

SASS vs. LESS

css-tricks.com

162 pointscobychapple58 comments

I think the individual comparisons are good, but the conclusion is wrong. Yes, Sass is technically superior to Less; it can do a lot of things that Less cannot. That does not mean that you should use Sass over Less.

The truth is, for 99% of use cases they are exactly the same. Sass is a bit more mature and it allows more programming, so it is potentially more powerful than Less, but that also allows it to deviate for CSS further, which is not necessarily a good thing if you have to work with people who only know CSS.

I personally use Less because it helps me develop faster. Less is implemented in JavaScript, which means it can run in the browser. Less.js' "watch mode" is awesome for speeding up development: save your .less stylesheet and the browser immediately shows the new styles. This is something SASS cannot do and.

Finally, to correct some factual errors in the article: Less does allow some programming, loops etc. It's just incredibly awkward and barely useful, but you can use JavaScript (I used that to make this: https://github.com/micheljansen/dynamicgif.less). Also, the "Helping with CSS3" point is moot if you use http://lessprefixer.com/ and keep that updated.

Sass has an implementation of "watch mode": sass --watch + livereload (either the guard-livereload gem or the app). This allows you to save you file and have the browser immediately refresh. If you use middleman to build out your templates this functionality is built in with "middleman server --livereload"

>Sass is technically superior to Less; it can do a lot of things that Less cannot. That does not mean that you should use Sass over Less.

No, this does mean that you should use Sass. This is how technical decisions are made. You create a list of categories with weights and then you score all available options and add their points. You then use the one with the most points. Y'know, the best one.

>This is something SASS cannot do and.

Sass also has a watch mode. Well, you'll need Ruby, but so what?

If you use a static website generator (like Middleman) for your quick and dirty prototypes, there is zero overhead involved. You use "example.css.scss" as file name and reference "example.css". That's all you have to do.

I think making CSS more like a programming language is a bad idea. Insofar as LESS lets you do dumb programming tricks in your faux CSS it's a bad idea. I think SASS is going in the wrong direction of putting more ability to create convoluted rubbish in the hands of people who create enough convoluted rubbish with simpler tools.

And I think the signs of activity on LESS vs. SASS reflect not that SASS is in mor aggressive development, although it might be, but tha LESS is more popular but the developers are more cautious in adding features.

> I think SASS is going in the wrong direction of putting more ability to create convoluted rubbish in the hands of people who create enough convoluted rubbish with simpler tools.

This sounds like maybe more of a people problem than a technical problem.

>I think SASS [...]

Based on what? Sass helps me to write cleaner, better organized code. Furthermore, it reduces typing work. It's great, really. There is a reason why more and more people are using it.

Did you see the vendor prefix debacle? With Sass/Compass, vendor prefixes aren't an issue anymore. Everyone who used Sass/Compass correctly was not part of the problem.

How do you handle sprite sheet generation? How do you handle cache busting of your background images? How do you handle vendor prefixes? These things are very annoying to handle if you have to do that manually.

You don't need dumb programming tricks to handle vendor prefixes. What I'm against is making CSS more complex.

He uses SASS and SCSS interchangeably. For anyone else not familiar with the difference:

"Sass consists of two syntaxes. The original syntax, called "the indented syntax" uses a syntax similar to Haml.[2] It uses indentation to separate code blocks and newline characters to separate rules. The newer syntax, "SCSS" uses block formatting like that of CSS. It uses curly brackets to denote code blocks and semicolons to separate lines within a block. The indented syntax and SCSS files are traditionally given the extensions .sass and .scss respectively."

http://en.wikipedia.org/wiki/Scss

Also:

"Sass and LESS both use the standard CSS syntax. This makes it extremely easy to convert an existing CSS file to either preprocessor. Sass uses the .scss file extension and LESS uses the .less extension. The basic Sass or LESS file can be setup like below:

...

As you may have noticed, this is just regular CSS, which compiles perfectly in both Sass and LESS. It’s important to note that Sass also has an older syntax, which omits semicolons and curly brackets. Although this is still around, it is old and we won’t be using it past this example. The syntax uses the .sass file extension and looks like this:"

http://net.tutsplus.com/tutorials/html-css-techniques/sass-v...

What about stylus?

http://learnboost.github.com/stylus/

http://visionmedia.github.com/nib/

More?

http://news.ycombinator.com/item?id=3945633

Some compiler geek should create a tool to translate code from one preprocessor to another, so mixin support would not be an issue.

We've used both Stylus and SASS. I've even contributed a few patches to Stylus. Ultimately, we decided that Stylus is a bit of a failed experiment in syntax/punctuation minimalism; SASS is much nicer to work with.

The key problem is that Stylus doesn't make a clear visible distinction between control structures, mixins, and other meta-level constructs. With Stylus, you can trivially override built-ins and it's very difficult to "go to definition", so to speak. SASS has very obvious symbols which call out the presence of preprocessor stuff. This makes it much easier to visually scan stylesheets and map what you're seeing in the inspector to what you're seeing in the source files.

Simply put, because the gap between CSS and the preprocessor language is so narrow, it makes sense to call out differences. Unlike, say, C and x86, it's too easy to look at Stylus and CSS side by side and be confused by their similarities.

stylus lets you write code as minimalistic as you want, meaning you don't have to do it to the max and get rid of everything.

Stylus is a nice concept, but when I found some issues or limitations, which is not unreasonable for a young project, it was not always obvious how it should actually work.

SASS is a more mature project with a solid design.

Do you know if the Stylus compiler works any faster than the SASS one? Long compile times were an issue for me when I was using SASS a year or so ago. Although come to think of it, maybe I could've hacked a workaround by splitting my CSS into more than one SASS project.

During an experiment, I hit the 4095 selector limit in IE <= 9. Even with that combinatoric explosion of preprocessing hackery, compilation still only took about 2 seconds with SASS. Sooo, I'm not really sure what problem you're having :-)

I've always considered SASS the only true successor to CSS.

LESS and SCSS are syntactically conservative. I feel they retain the grammatical conventions of CSS (curly braces) as a way to ease the learning curve for conservative developers.

They introduce developers to the powerful features (mixins, variables) of extended CSS. But retain their familiar CSS curly bracket syntax.

Eventually it makes sense for said conservative developers to take the next step and adopt SASS's clean syntax.

Definitely seconding this, sass is a much better syntax than CSS, it's the difference between coffeescript and javascript, simply much less line noise and very sane defaults.

That said, I'm not sure why haml isn't as popular as sass.

I'm assuming you did not mean to come off so sneeringly, but your claims that LESS retains bracing because it's "easier" reads as contempt rather than the recognition that maybe, just maybe, the syntax you call "clean" is what someone else--like, say, me--would call "unreadable and annoying".

Personally, I like bracing, because it is a better visual indicator, for me, of structure. I dislike indent-based blocking (Python, SASS) because I think it looks cluttered; I like brace-based blocking (C, LESS) because they're unambiguous and stand-out 'signposts' for my eyes as I read code. (I'd use SCSS if it wasn't Ruby-based. I like tools I can hack on and working in Ruby is, for me, a miserable experience.)

There are more reasons make that stylistic decision than "it's easier", even if you don't like it and even if, heaven forfend, it's not part of what you consider "the only true successor".

I like braces.

There is also another advantage to Less/SCSS, which is that existing CSS files are already compatible, so you can start a gradual migration without effort.

This means for instance that an outside designer, that does not know Sass, can come in and contribute directly to the codebase without his workflow being disrupted and without me having to tutor him in Sass. This is how design works anyway - you start with a bunch of PSDs that get accepted, you transform that into static HTML and CSS (that have to be emailed around and approved), then you start adding dynamic features, you then go back to the designer to fix the design in case the dynamic content doesn't blend well, then you start refactoring the HTML/CSS to be clean and easy to maintain ... but this is only the last step, because the other steps, like getting the design right, are more important.

When you say that Sass should be the true successor to CSS, you're thinking like a programmer. I also wish that Gimp would be the true successor to Photoshop, but that won't happen.

> There is also another advantage to Less/SCSS, which is that existing CSS files are already compatible

Not sure about SCSS, but in my case Less choked on some complex hacks like IE filters. Not arguing about their evilness, but the fact remains—not always you can simply rename .css to .less and gradually start using new features. (In the end I kept CSS as is, with a separate Stylus file with overrides and new styles. SCSS wasn't an option, and I have a feeling it also suffers from these issues.)

That was an awkard conclusion on "Active Development". The total number of issues and pull requests on LESS dwarfs that of SASS, so a larger number of open/pending ones is natural. Some more numbers:

    Watchers:
      SASS: 1022
      LESS: 5480

    Forks:
      SASS: 138
      LESS: 731

    Total issues:
      SASS: 390
      LESS: 809
 
    Total pull requests:
      SASS: 62
      LESS: 199

That's a clear win for LESS in my book.

    Number of commits in the last month in LESS: 11
    Number of commits in the last month in SASS: 35

that's the important part.

Simply looking at commits/month doesn't tell us anything. Want to compare size of commits? Lines affected? Comments vs code? Code vs tests? I think the general picture is much more favorable for LESS. If anything, there's a hundred people ready to pick up development at any time.

> a hundred people ready to pick up development at any time.

I really wish that was true. From my experience, almost every time I jump to the forks sections of libraries I'm using (or interested in using) I'm disappointed when I see that 99% of thos forks contribute nothing. Forking by definition was a serious move, now (on github/bitbucket) it's not - most of the time it's just one-click copying the project to your own collection and it's just noise when I'm really looking for an alternative fork. Just my 2 cents why I'm not impressed by numbers of forks as a project sustainability measure, it's not an opinion on less/sass specifically.

I've seen this argument a few times. Forking on github is just the fastest way to try something out with the codebase and/or make a pull request. That was happening before, in a smaller scale, you just couldn't see it. I think the number of forks directly reflects the size of the community and traction.

I agree that it's hard to find real forks, watchers are a good indicator but you can't search/filter by that. On the other hand, meaningful forks tend to change their name the moment they detach from the original.

You certainly have a point, I just too often came across projects updated 1 year ago or earlier with 50 forks and any further support in there. Maybe code hosting providers could by default hide from the project page the ones that haven't contributed anything (I know they won't do it, they like the big numbers).

At JSConf Alexis was wishing someone would take over project maintenance and free him up entirely for LESS project direction & language design. The relative commits are quite relevant.

LESS became popular thanks to Twitter Bootrstrap and to the fact that you don't need Ruby to use it, which is a big plus for Windows users.

I use them both on daily basis, SCSS & Compass for a Sencha Touch project and LESS & Bootstrap for web dev work, along side with CodeKit to compile them and the major difference that I see is the speed of compiling. The projects I work on are both pretty large and with many .scss/.less files but LESS compiles way faster for me and this is a big plus.

Also, LESS is pretty useful for rapid prototyping since you can use the less.js and skip the compiling part altogether.

I use SASS on Windows with no issues and it was rather easy to get up and running. Granted it did require the installation of Ruby of which I only use it for this, but that's a small price to pay.

Indeed. IMHO the concerns expressed by some here about relying on Ruby are greatly exaggerated.

For anyone who is curious, the steps required to use SASS on Windows are something like:

1. Download RubyInstaller from rubyinstaller.org and run it. (This is a self-contained Windows installer for Ruby and the related tools/documentation.)

2. Run "gem install sass" at a command prompt. (This downloads and installs SASS itself, including SCSS.)

Personally, I'd love it if Ninite picked Ruby up as an option, because I already install many other tools that way in a single step. However, installing Ruby manually is no harder than installing any other piece of Windows software you download, and installing SASS on top is literally a one-liner.

Unless you're developing on a relatively old and low-powered system, I don't see any downside to having the extra software installed either: it's just another tool, occupying a few MB of hard drive and a few characters in your PATH, and IME it's perfectly friendly toward development toolchains for other languages.

Your two-part explanation is accurate. The Sass team was nice enough to even point you to RubyInstaller right there on their download page.

> you don't need Ruby to use it, which is a big plus for Windows users

Not just. It's a plus for someone who already uses CoffeeScript in a Django project and don't want to bring in another huge piece of infrastructure as a dependency.

> you don't need Ruby to use it, which is a big plus for Windows users.

Not only that, but if you are minifiying Javascript some of the best minifiers are built with node, so its one less language/dependency if you're not already using ruby.

Mindscape has a Visual Studio extension called "Web Workbench" that makes installing and using SASS really easy (as well as LESS and CoffeeScript). I installed via NuGet and I don't remember ever having to leave Visual Studio. The installer took care of all the dependencies and I was up and running right away.

So, at the point CSS becomes a programming language of its own I'd rather just use java script. Somebody should come up with some way to define you style data in JSON, then parse and process the data on load.

http://www.w3.org/Submission/1996/1/WD-jsss-960822

I ran across this the other day (it's a dependency of jsdom)

cssom - https://github.com/NV/CSSOM

* edit: fixed typo

Sass also has Susy, which is just a superb grid system. I can't adequately express in words how much I love this grid system. It's mahtava.

http://susy.oddbird.net/

This is a really good writeup and I really appreciate the bit at the end about pull requests and issues as I do feel that developers should stay on top of their communities. That said, I like the mixin syntax of Less better and my favorite project Bootstrap uses Less, so I'll stick with Less.

Same here, Bootstrap has a ton of momentum and the mixins abstract away worrying too much about the vendor prefixing stuff anyhow.

Horses for courses, the real story is that these pre-processors are getting serious traction.

Agreed on the syntax, but for me the bigger issue that keeps me with LESS is that I have no interest in using a Ruby project for something integral to my build process because then I can't hack at it without a bottle of antacid. I don't work in Ruby and I have a strong desire not to; on the other hand, while I don't claim to like it, I'm quite comfortable with JavaScript and can work with LESS's code if I need to (and it has come up in the past).

This is one the reasons Hampton Catlin (the original author of Sass) created libsass, a port of Sass to C for portability. Check it out: https://github.com/hcatlin/libsass

Huh, never saw this! And it does seem to support SCSS (I don't like the SASS style at all). I'll have to take a look at this more closely.

Thanks!

Is it safe to assume that this compiles CSS much faster than the original?

After some brief testing: definitely. Faster than LESS by a good bit, too.

I'm not sure I'm going to use it, because of the compiled dependency (I'm on a Scala/Vert.x stack and I like being able to just check it out and hit "go"), but it's at least a practical option for me and I'm glad it exists.

Who cares if it's written in Ruby? You never have to see a single line of Ruby code to use it.

Did you actually read my post before replying? I much prefer to be able to, if necessary, work with the tools in my build process at a code level. I don't enjoy working with tools I don't have mastery over wherever possible (pgsql is a stretch, but I can hack on nginx, Play, LESS, and Redis without much difficulty).

I have on occasion had reasons to be mucking around in the LESS codebase. I cannot do that with SASS (well, I could, but I'd have to use Ruby and that's a non-starter for me).

There are sass ports of bootstrap, specifically the compass_twitter_bootstrap gem. I've been switching my projects over to this since discovering it.

Good write-up

Not sure on my history here but i'm pretty sure i remember only the SASS variant being available (no braces among other things) while LESS stuck to a more css-like grammar. later SCSS came along which was CSS grammar for SASS.

It seems like I've run into more projects using LESS -- anyone know of any statistics?

IMO, SASS ~= LESS, but Compass > *. Damn shame that Twitter Bootstrap went with LESS.

Then there is this:

https://github.com/thomas-mcdonald/bootstrap-sass

All the twitter bootstrap mixins available to you in sass format.

It's Sass not SASS.

http://sass-lang.com/

The author makes the point that LESS uses the `@` for a variable identifier while SCSS uses `$` (and that he feels this is better) but CSS4 spec today says it will use `$` for parent selectors.

http://www.w3.org/TR/selectors4/#subject

I don't do a lot of FE dev but I can count the number of times I've used `@` on one hand. However, I could see myself making use of `$` as a parent selector quite often. How would SCSS adapt to this?

As far as I'm concerned, Less, Sass and Stylus all provide the features for the way I like to write styles (DRY, with composability) so the main thing that influences which I'll use on a project is how easily it fits into the workflow. That means Stylus for Express projects, Sass for Python/Flask.

When I'm at my day job I use Less (well, more specifically Lessphp) for the simple reason that there's a Drupal module for it, which integrates very well with building Drupal sites.

That looping construct in LESS is rather reminiscent of C++ template metaprogramming. Or ML/Haskell without higher order functions.

This comparison distracts from better stuff out there: http://therain.posterous.com/sass-scss-lessthey-all-suck

I find that harder to read than if it had a : separating the attributes.

You can use it if you want, punctuation is optional.

http://learnboost.github.com/stylus/

It seems his only argument for using Stylus is because it doesn't use brackets nor colons? That's it? Sorry, that's not a good enough reason for me. That's just a coding style opinion and does nothing to suggest it is superior to other options. What "real" features does it offer that the others do not?

Can we get past this silly attitude that my coding style is better than your coding style even though the outcome is the same?

Reply on news.ycombinator.com