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?
SASS has more developer community and support than SCSS. SASS supports SassDoc to add documentation whereas SCSS allows inline documentation. SASS can't be used as CSS and vice-versa whereas a valid CSS code is also a valid SCSS code.
Sass facilitates you to write clean, easy and less CSS in a programming construct. It contains fewer codes so you can write CSS quicker. It is more stable, powerful, and elegant because it is an extension of CSS. So, it is easy for designers and developers to work more efficiently and quickly.
Stylesheets are getting larger, more complex, and harder to maintain. This is where a CSS pre-processor can help. Sass lets you use features that do not exist in CSS, like variables, nested rules, mixins, imports, inheritance, built-in functions, and other stuff.
Sass adds a lot of "nice" features Even though nesting is coming to CSS, the Sass version is here today and it has more features than the native CSS nesting will have. For instance, we don't need the & in Sass, making it feel more intuitive. And we can nest media queries inside selectors.
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 :)
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With