Why use Sass (not SCSS)? [closed]

问题:

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 4 years ago.

everyone — I was looking over a recent presentation on 960 Grid System, Refresh OKC – April 19th 2011, and on the penultimate slide (101/102), the guy recommends "if you're going to use Sass, use Sass, not SCSS." Given that SCSS is the new main syntax, why prefer Sass to SCSS? Is it simply a preference for conciseness over similarity to CSS, or is there a real reason for using Sass, not SCSS?

回答1:

I can't think of a good reason :)

I looked at the whole set of slides, I think the presenter (who is also a connected to the SASS project, I think anyway?) is of the mindset to use what you know to "get 'er done"

Sass is supposedly shorter and more concise and it's possible that the speaker knows Sass inside out, but speaking from personal experience having read and written CSS for over 10 years I find SCSS much more intuitive. I do not have to learn the Sass indentation rules, and the brackets in SCSS and CSS provide visual indentation clues for nesting - which is very like most every other language uses, so anyone from a programming/coding background would be familiar with the idea of closing the nests??

.. more importantly every valid CSS is already a valid SCSS so no conversion needed to start using it - e.g. I was able to take my Drupal sheets (all 29 of them!), change their extension and recompile/compress them in very little time.. since then I've been able to take a little chunk at a time and "Sassify" it, using nesting etc. and I still like to see the brackets and semi-colons, it matters not, which you use once it's all compiled anyway!

IMHO Sass itself is too high a barrier to entry for a large project (existing one, i.e. one not built/sassified from scratch), where as it can be modularised with SCSS

So to follow the original author's (of the slideshow) thinking rather than debate pro's and cons I'll just keep using the one I know TYVM :)

回答2:

I believe that the bracketed .scss syntax is currently the default only because it is more familiar to newbies who switch to SASS from LESS and vanilla CSS.

The indented .sass syntax was the first in SASS, being identical to (and making an ultimate team with) HAML. The new bracketed .scss syntax is similar to LESS, a competitor of SASS, both SASS and LESS make it possible to convert from CSS just by renaming.

The indented .sass syntax has only one drawback: it does not allow splitting function/mixin arguments into multiple lines. That can make the code harder to read (example).

In practice, this problem is rare and might be an indication that the code is poorly designed and requires refactoring.

The only yet decisive advantage of the indented .sass syntax is that it is much cleaner and easier to comprehend, while being equally expressive and powerful.

I have created an animation for you to consider the difference:

Also, didn't you hate it every time when your code failed to work/compile due to a semicolon missing (and maybe the interpreter/compiler producing a misleading error message)?

Basically, the indented .sass syntax just removes bloats of visual noise.

Of course, it requires some time to get used to it. At first it looks alien to anyone who has some experience with CSS or LESS. But once you get accustomized a bit, you'll find yourself feeling distaste to the bracketed syntax of CSS/LESS/SCSS and JavaScript and preferring the clean syntax of SASS, HAML, CoffeeScript and Python/Ruby.

回答3:

Pros: It's cleaner. Less visual noise. More elegant.

Cons: The big one: Can't use newline. This is the only thing that I don't like about SASS. See example below. The rest: Higher barrier to entry for people who struggle with the apparently difficult concept of indentation.

In SASS you are forced to stick to lines. So if you have

@function -create-gradient-from-color($bgcolor:#000,$depth:6%)
    ...code...

then you can't do this, which i find much cleaner

@function -create-gradient-from-color(
    $bgcolor:     #000,
    $depth:       6%
)
    ...code...

That will throw an error because of the newlines.

But you can do that in SCSS, since it doesn't care about newlines

@function -create-gradient-from-color(
    $bgcolor:     #000,
    $depth:       6%
) {
    ...code...
}

So I find myself keeping things terse in optional argument strings to prevent this situation.

回答4:

I find SASS much faster to type.

SASS and SCSS both are a huge add-on to CSS - so different that I don't want to confuse them with standard CSS.

It's not hard to learn SASS - lose the brackets, and use tabs to decide nesting.