Sass: Don’t Give me That CSS

Adam Collins
FullStackHacks
Published in
6 min readMay 16, 2017

CSS preprocessors have been around for a while and there are a lot of them out there. Despite so many preprocessors they’re all variations on the same theme. They add a little syntactic sugar on top of bland CSS to it easier to read/write. CSS doesn’t support things like variables, (although CSS4 will change this) or nested selectors. This can lead to a lot of repeat code. Unlike my humor CSS code is exactly DRY. Unlike my humor CSS code is exactly DRY. (DRY stands for do not repeat yourself).

Sass is the most commonly used CSS preprocessor. According to one survey 66.0% of developers use Sass while 13.4% used Less and 13.5% didn’t use a preprocessor. (These number should be taken with a heavy dose of skepticism as the survey only include ~1,000 people).The popular front-end framework bootstrap switched to Sass from Less a couple years ago. Sass has 92mm ruby gem installs compared to 5.2mm Less installs. Personally, I use Sass (the .sass variant) but I don’t believe the preprocessor you use makes a huge difference. That being said, this article is covers Sass, but a lot of the information presented applies to all preprocessors, so feel free to experiment and find the best solution for your needs.

Sass stands for syntactically awesome style sheets. It first appeared back in 2006 as a part of a HTML preprocessor called Haml. Sass was conceptualized by Hampton Catlin and Natalie Weizenbaum. Today there are actually 2 versions of Sass. There’s Sass (.sass extension) and SCSS (.scss extension). SCSS stands for Sassy CSS. Sass and SCSS are more or less same except SCSS uses curly braces and semicolons where as Sass relies on new lines and indentations. The big advantage of SCSS is that it’s CSS compliant so any CSS code can be copy and pasted into a SCSS file. That’s useful for when your working with large legacy code base who’s development team doesn’t want to go through and convert all their CSS code to Sass (there are tools for this, but who wants to use yet another tool?). SCSS also tends to have better compatibility with dev tools. Little things like syntax highlighters often have more support for SCSS as the syntax is similar to CSS. For these reason SCSS is by far the more popular version of Sass.

So, while I don’t agree with it I understand the argument for SCSS and I don’t blame people for using SCSS. One thing that confused me though, when I was doing my research, was that I stumbled across this article on Sass vs SCSS. The author of this post, Hugo Giraudel, ostracizes Sass. He made claims that Sass uses equal signs instead of colons as well as some other syntax quirks. Which equate to this scary looking mess:

While my understanding is that this would written like:

The latter is much easier to understand. It’s similar to CSS in that attribute values are declared with a “:” instead of a “=”. Also, variables go from “!” to “$” which is a big deal since in CSS “!” is a reserved character for important. Needless to say, this article thoroughly confused me. It made me question my own Sass code/compiler, which throws errors when I declare a variable with “!” or use equal signs instead of “:”. So, I did some more digging and I found this set of slides published in June 16th, 2008. The slides cover Sass and Haml, but the Sass code in it again uses the same strange syntax that Hugo mentioned.

So a little back story here: It’s fairly well known that originally Twitter chose to use LESS instead of Sass for Bootstrap. LESS didn’t appear until 2009, 3 years after Sass. After LESS gained some popularity the Sass project released the SCSS variant. SCSS has now become much more popular than Sass, because it’s brings back the curly braces and semicolons. Meaning that the above example looks likes this:

This is where I get confused on the history and wasn’t able to find any solid answers, so if anyone could clear this up for me in the comments I’d happily give you a s/o in the article. So, SCSS was inspired by Less. I believe what happened is Sass realized being different isn’t always good. So they created the SCSS variant after they saw Less’s success. However, at what point did the Sass syntax change. If I try to use an exclamation mark to declare a variable now I get an error (as I should since “!” is important in CSS code). Was the exclamation mark just used in Sass when it was a part of Haml? Haml does use “!” for variable declaration so it would make sense that this would be continued into Sass. Did Sass completely change the syntax after Less when they decided to use SCSS? This would make Bootstrap’s decision to chose Less at first and then switch to Sass after the syntax overhaul more understandable. (Sorry for the tangent, but these questions have plagued me throughout my research).

Regardless of the old-new Sass debacle, I can confidently say that Sass is now great and doesn’t use “=” for attribute declaration or “!” for variables. Variables are an integral part of Sass. One of the biggest issues with CSS is repeat values. For example you may want to use a certain color palete throughout your site. With traditional CSS if you want to make a change to that color pallette you would need to hunt through the code to find each instance of a color and then change it. This method is tedious and prone to mistakes. With Sass you can simply do this:

The first line declares a variable named “$brand-color” (it has to start with a $ not an !). Then that variable can be used in replace of blue. If I want to change it to red all I have to do is update the variable declaration and Sass will handle the rest. Variables make it possible to maintain consistency even on the largest web application.

One of my favorite features of CSS preprocessors are nesting. CSS doesn’t support nesting and I have no idea why. Nesting is a logical way to style your applications. A nested Sass file mirrors the structure of the html document; making it much easier to understand/read. Take this html example:

In order to style just the h1 tag and p tag in css you’d have to write

While in sass you could write:

Noticed how the h1 and p are nested inside of the .level-3 block this not only save developers from having to repeat the series of selectors, but it just makes sense. Nesting is my favorite feature in Sass. It is one of those things that I can’t live without now. I find it much easier to understand and read, added bonus is it’s often few lines of code since you don’t need to repeat selector definitions.

Another big feature in Sass are mixins. Mixins enable developers to put repetitive code into these nice maintainable function-like statements. One situation where this is useful is for vendor prefixes. Remembering/writing all the vendor prefixes can be a pain; so Sass developers will often put them inside of a mixin like so:

The first line declares a mixin called border-radius that takes a single parameter $radius. Then defines a block of code with that variable. On line 7 the button class is slected and at line 8 the mixin is include with $radius given a value of 3px. The Sass compiler will then output this:

This saves on a lot of repeat code. Part of the reason Sass is as popular as it is is because of mixins. One of most well known Sass project is Compass which includes mixins for all sorts of things from horizontal list to vendor prefixes. I’ve only scratched the surface of Sass there are more features including Extend/Inheritance. The ability to do numerical operations in your style sheets. You can import styles from other files; making it easier to maintain. Sass is one of the few tools that I recommend to everyone including beginners. It’s truly a better version of CSS in every way and I think it’s easier to learn than CSS. I now use Sass whenever I can.

Interesting Links

--

--