A couple days ago, I was mindlessly scrolling through my Facebook Newsfeed when, out of the banality of the usual status updates, one arose that caught my attention. It said, “Sass, SCSS, LESS or CSS. Which is better?”
This spawned a lengthy detailed comparison of Sass vs. SCSS vs. LESS, which I later deleted and truncated into something more readable (because no one wants to read a Facebook comment that’s more than three paragraphs long). But afterwards, I realized I really wanted to take a deeper look into the world of CSS preprocessors, and share them properly with the world.1
WHAT’S A CSS PREPROCESSOR?
CSS has always been a solid foundation of styling our websites. But in recent times with new web design trends, browser capabilities, and screen sizes, a demand grew for a way to streamline, organize and maintain our massive stylesheets.
In swoops Sass. Five years ago, a couple of developers named Hampton Catlin and Nathan Weizenbaum developed a new way to write CSS. They called it Sass, which stands for “syntactically awesome stylesheets.” These new stylesheets had a new syntax, which then used a preprocessor to translate into regular CSS for all browsers to read. It’s like taking the abbreviated text messages of a pre-teen girl and translating it into proper English.2
JUST SOME BASICS
Let’s take a look at an example of how you would style a menu using Sass, SCSS and LESS. To begin, let’s write out the HTML and the CSS of this menu, something we should all be familiar with. We’ll be focusing on the syntax of these languages, so I apologize for the lack of pretty pictures. They’d all look the same anyway!
When Sass first came out, it was a culture shock for developers and designers; there were no curly brackets, you had to indent a certain way, and you had to learn new symbols. Many designers ran away from it with their tails between their legs, but some of the braver developers took on this new challenge and are still using this initial version of Sass.
In Sass, your CSS is stripped down, plain and simple. Child selectors are nested within the parent, and indented accordingly. The ampersand (
&) is then introduced as a shortcut to refer to the parent selector at the nested level. You can establish constants to be used throughout your stylesheet (declared with the ! operator). That way, if you—or your client—suddenly decide that
!menu-bg should be a different color, you only need to change it once at
!menu-bg rather than searching your entire stylesheet for every instance of the old color and changing it.
Sass also allows you to write math. In this example, the hover color is a darker shade of
!menu-bg, so we subtract
#111 from it which gives us
#b3011f. If the color of
!menu-bg is ever changed, Sass does some slick math and automatically makes the hover state darker (or lighter, or whatever your equation dictates) accordingly.
Sass uses strict indentation hierarchy, saving you time and repetition. For the obsessive-compulsive coder (like myself), Sass’ rules about indentation forces you to write your code the same way each time, making it easier to read especially if you’re working with a team.3
Because of Sass’ strange new syntax, developers started complaining. Why spend time learning something so foreign only to have it translated to the language we already know?
Thus, SCSS (Sassy CSS) was introduced. It became an extension of Sass, so it’s not too different from its predecessor, but the advantage is that it uses the existing syntax of CSS. Basically, it takes the best of both worlds; you have the indentation structure of Sass while retaining the rules of CSS that you already know.
The dollar sign (
$) is used to declare variables because the exclamation point is already used in CSS (for
!important directives) and it just seemed silly to use the same symbol in different contexts.
For most people (myself included), SCSS is preferred over Sass because of its similarities to CSS. If you know CSS, then SCSS is a piece of cake. Sass has a slight learning curve to it. Also, being the obsessive-compulsive coder, I appreciate the use of curly brackets and semicolons. The indentation doesn’t matter all too much at this point, but I do it anyway.
And the best part is, any CSS is also valid SCSS.
In 2009, a developer named Alexis Sellier created LESS, based on the syntax of Sass, which later inspired SCSS.
Since these three languages inspired each other, they’re pretty similar in structure. Once we get into conditional logic, we’ll see more of a difference. For now, the only difference is while SCSS uses
$ to handle variables, LESS uses
For some, the LESS
@ sign creates a personal annoyance since it is also used for declaring
@media queries, but ultimately is not problematic.
IS THAT IT?
Not at all! This is just brushing the basics to get your feet wet with the syntax. Later, we’ll dive into
extends, and explore how SCSS/LESS handles expressions, functions, and conditional logic!
In the meantime, if you’d like to check out the world of CSS preprocessors for yourself, head on over to some of these resources:
1. This post contains highly geeky content. If you’re not familiar with HTML or CSS, the following content might make your brain explode. You have been warned. ↑ back to top
2. omg srsly? totes cool lol. ur my bff 4lyfe. ↑ back to top
3. Kevin has yelled/groaned/laughed at me many times for changing the structure of his CSS. Likewise, I have also yelled/groaned/laughed at him for changing mine (or because I felt like it). Kevin also yells at Jereme and Andre (and vice versa), because at some time, I had forced them to conform to my style of writing CSS (they may deny this). ↑ back to top
5. Or disastrous. ↑ back to top