happy little biz

Why use Sass instead of plain ol' CSS?

Ok, all of you experienced front-end devs are probably thinking one of two things:

“Sass? Nah, I've been coding since forever, and I like my vanilla CSS!”

or

“Yeah, already with you on preprocessors. In fact, I'm partial to [Less/Stylus] and I'm also using [HAML/Jade/CoffeeScript]… ”

And that's cool! But for the less experienced, who might be thinking:

“CSS is tricky enough as it is! Why complicate it further? ”

or

“I'm interested in preprocessors but I'm not sure where to start!”

this post is for you.

Sass!

Isn't Sass the thing your grandmother told you not to do?

Well, I suppose it is that. But it's also a nifty CSS preprocessor. Our friends over at CodeKit put it this way:

Sass is what CSS should be. It adds variables, nesting, mixins and more to regular CSS.

In other words, it takes CSS, a language that gives most programmers a headache, and adds in functionality that most programming languages already have. This makes it more useful, quicker to code, and easier to maintain. Which means less headaches!

What's a preprocessor?

A preprocessor is exactly what it sounds like: it takes some code, processes it, and then outputs it into another format. In this case, it takes a Sass file, processes it, and outputs CSS you can use in your project.

Do I have to learn a whole new language?

Luckily, no! That's what's so great about Sass - it's very easy to learn.

Sass has two syntaxes: SCSS and Sass. The Sass syntax is the older one, and is a bit less like vanilla CSS - it uses indentation instead of brackets, and newlines instead of semicolons. It's easy to learn and nice and clean looking, but not as intuitive as the SCSS syntax.

With SCSS, anything that is valid CSS3 is valid SCSS. So if you can write valid CSS3, you'll likely find that SCSS just seems natural. In fact, if you're anything like me, within a few minutes of testing out some SCSS, you'll find yourself saying “This is what CSS has been missing all along!”

Hmm, sounds interesting. Give me the elevator pitch.

Ok! If you're like most developers, you find CSS to be a bit of a pain in the butt. Let's be real here: it's a complex language to learn. You've got all the different selectors, transitions, transformations, plus browser compatibility issues, cascade issues, and general quirks. But what if you could make it much easier to use?

In CSS we repeat ourselves a lot. For example, say you wanted to use the border-radius property a few times in your style:

.blog-logo img {
    -webkit-border-radius: 50%;
    -moz-border-radius: 50%;
    -ms-border-radius: 50%;
     border-radius: 50%;
   }

 .post-header img {
   -webkit-border-radius: 20%;
   -moz-border-radius: 20%;
   -ms-border-radius: 20%;
    border-radius: 20%;
 }  

  .portfolio p {
  -webkit-border-radius: 10%;
  -moz-border-radius: 10%;
  -ms-border-radius: 10%;
   border-radius: 10%; 
   }

Kind of a pain with all the different vendor prefixes, right?

With Sass, we can do this instead:

@mixin border-radius($radius) {
   -webkit-border-radius: $radius;
   -moz-border-radius: $radius;
   -ms-border-radius: $radius;
      border-radius: $radius
      }

.blog-logo img{
    @include border-radius(50%);
}

.post-header img{
    @include border-radius(20%);
}

.portfolio p{
    @include border-radius(10%);
}

You can reuse that border-radius mixin as many times as you like, and you never have to remember all the different vendor prefixes - as long as it's in your mixin, you're good to go.

Cool, right?

Why else should I use Sass?

It makes your code more DRY. No, not dry as in boring or a dry sense of humor. Not dry as in the opposite of wet… well, errr, actually we do kind of mean that. DRY, or Don't Repeat Yourself (the opposite of WET, or We Enjoy Typing), is what we should strive for in programming.

Let's be honest: CSS isn't DRY at all. We tend to repeat the same colors, font stacks, and style patterns multiple times for the same stylesheet. But we don't have to, because Sass allows us to create variables and mixins.

Here's a few more examples, which I admit I borrowed from the Sass guide.

If you work with pretty much any other language, you're probably familiar with variables. Adding variables to CSS make your code much more DRY, and also make it MUCH easier to update:

$font-stack: Helvetica, sans-serif; 
$primary-color: #333;

body {
    font: 100% $font-stack;
    color: $primary-color;
}

That becomes this CSS:

body {
      font: 100% Helvetica, sans-serif;
      color: #333;
}

If you used that font stack and color several times over, and suddenly wanted to change them? No problem! Just update the variables. Done.

You may also be familiar with nesting, which allows you to organize your code much more effectively. Here's an example of that:

nav {
    ul {
        margin: 0;
        padding: 0;
        list-style: none;
      }
      li { 
        display: inline-block; 
      }
      a {
        display: block;
        padding: 6px 12px;
        text-decoration: none;
      }
}

That will output this CSS:

nav ul {
     margin: 0;
      padding: 0;
      list-style: none;
}
nav li {
      display: inline-block;
}
nav a {
      display: block;
     padding: 6px 12px;
      text-decoration: none;
}

As you can see, nesting helps make your code easier to read - as long as you don't go too overboard with it.

Do I have to learn to use the command line?

The short answer is: nope! There are nice apps out there that will do the compiling and installing work for you. I've already linked to my own preference, CodeKit, but there are others such as Compass.app, Koala, and Mixture.

But really, I promise you don't need to be afraid of the command line.

Now, I've been using the command line as long as I've been using a computer, so my answer is of course biased by that experience. For me, firing up a terminal window to use ssh, git, or basic system commands is no big deal.

For Sass, there's very little you need to do in the command line. In fact, it's really just one command you need to learn. So if you have command line phobia, don't let that stop you from trying Sass!

One other really good reason to try out Sass, or another preprocessor if you'd prefer to: It helps you stay ahead of the curve. As Tuts + points out, things like nesting and variables will eventually be part of regular CSS. Why not learn how to use them now?

One more thing! What the heck does Sass stand for, anyway?

Sass is generally said to be a backronym for Syntactically Awesome Style Sheets. But Hampton Catlin himself said it's really whatever you want it to be. So if you want to call it something else, go for it. Just do try it out!