Sass compared to SCSS

Sass is a language and a syntax. SCSS is a syntax of Sass. Both syntax support the same features equally. Throughout the book, I will interchangeably refer to Sass as the language and the syntax. SCSS will only refer to the syntax of the language.

The easiest way to identify Sass, of course, is the lack of semicolons ; to separate declarations, or curly brackets { ... } to separate selector rules or blocks as shown in this example.

.block  // no opening curly-bracket
  font-size: 1em  // no semi-colons
  color: $text-color
  border: 1px solid $border-color
  // no closing curly-bracket

Advantage: Less characters to write. Style of writing that enforces code standards. Disadvantage: Any conventional CSS needs to be converted before it can be used. Using Sass meant learning a new style of writing for CSS.

SCSS, on the other hand, brings back the more familiar CSS appearance with the use of semicolons ; to separate declarations and curly brackets { ... } to separate rules as shown in the following example.

.block {              // opening curly-bracket
  font-size: 1em;     // semi-colons separating declarations
  color: $text-color;
  border: 1px solid $border-color;
}                     // closing curly-bracket

Advantage: No conversion required. Any correctly formatted CSS can be imported. Converting whole sites to SCSS simply means updating .css to .scss . If you are already comfortable writing CSS, you are good to go with SCSS. Disadvantage: Curly brackets { ... } and semicolons ; are back. CSS selectors are required to be more expressive.

I should also mention that all valid forms of writing CSS is now acceptable in writing SCSS. Illustrated in the following example, you will see the familiar CSS writing styles of expanded, nested and compact. Without a doubt, we will leave compressed for magnification and not illustrate that as an acceptable writing style.

// Expanded
header {
  width: $header-width;
  height: $header-height;
}

// Nested
header .nav {
  text-decoration: none;
  background: $background-color;
  color: $text-color;
  border-radius: $default-radius $default-radius 0 0; }

// Compact
header .nav p { font-weight: bold; }

SCSS' ability to combine different styles of writing is embraced by many of Sass' power users as illustrated in this sample CodePen example by John Long where he is creating a mixin using the @content directive.

@mixin keyframes($name) {
  @-webkit-keyframes $name { @content }
  @-moz-keyframes $name { @content }
  @-o-keyframes $name { @content }
  @keyframes $name { @content }
}

Sass, on the other hand, requires this code to be written in the following way, illustrating the necessity of whitespace.

=keyframes($name)
  @-webkit-keyframes #{$name}
  @content
  @-moz-keyframes #{$name}
    @content
  @-o-keyframes #{$name}
    @content
  @keyframes #{$name}
    @content

While SCSS supports a combination of writing styles that authors have come to appreciate, Sass' streamlined code writing style has a few shortcuts that are desired by many SCSS authors. A common feature, mixins, only requires a + symbol followed by the name of the mixin and the optional argument(s) as shown in this example.

block
  +buttons($button-color)

Whereas SCSS requires you to be more expressive, the full @include statement is required as shown.

block {
  @include buttons($button-color);
}

Sass' shorthand style of writing also carries forward when creating a new mixin. Notice the new mixin buttons is created by only using the = symbol.

=buttons($color)
  border-radius(3px)
  bacground-color: $color
  line-height: 1.5em

Whereas again, SCSS' expressiveness requires the full @mixin directive to be clearly stated.

@mixin buttons($color) {
  border-radius: 3px;
  bacground-color: $color;
  line-height: 1.5em;
}

Other directives like @extend and @function currently do not have a shorthand versions in either the Sass or SCSS syntax.

Probably one of the more interesting uses of SCSS is to import vendor styles written in CSS. As a matter of convention, I will create a folder in my Sass directory called vendor and include all my vendor specific CSS. By simply updating the file type from .css to .scss, these styles are now part of my Sass architecture.

Currently there is a debate about the ability to directly import a CSS file. While this can be accomplished within a Rails project via the asset pipeline, this is not a feature that Sass directly supports. I feel that there is some logic to this decision. It is definitely considered best practice that once you start using Sass that all your files should be Sass and that having a mix of Sass and CSS can only create more problems then it solves.

One of the luxuries of working with a preprocessor is that at any time you can toss the temporarily processed CSS files and re-process your Sass. But if you have a mix of Sass and CSS files in your project, this increases maintenance complexity. I don't like things to be unnecessarily complex, so 100% of my processed CSS comes from either Sass or SCSS files.

This is not to say that this solution is for everyone. If you are a user that requires additional CSS resources to be included as native CSS, Chris Eppstein released a Gem that will do this for you. The Sass CSS Importer Plugin, as Chris describes it, "The Sass CSS Importer allows you to import a CSS file into Sass."

In this section I took us on a short journey from the days when Sass was just a gleam in Hampton's and Nathan's eye all the way to present day when Sass has matured into a fully featured language that supports to distinctly different writing styles. Each style with impassioned users on either side. In the end, one is not better then the other and these different syntax types were created, and continually maintained, to serve different purposes.

It is up to you, the user, to decide what is best for you. Myself, I have taken the journey 360. I stated with the original Sass syntax, fully converted over to SCSS and now find myself easily writing both. Use each syntax to their strengths. Don't be overly dogmatic for one over the other, I hear these silly arguments all the time. There is a lot to be gained by simply understanding why someone else may prefer one style over the other.

Now that we know where Sass came from, in the next section I will discuss best practices for how to write clean Sass that will keep you from being a pain in the Sass to your team.