Introduction to Sass: Part 1 – Installation

I've been using preprocessors for years on pretty much every CSS project I do. Some might say that I'm lazy and preprocessors help me to be more lazy, but they work for me and my process. I believe that they help me be more efficient and productive. I'd encourage you to use a preprocessor and see if it fits into your workflow.

In this series, I'll be focusing on CSS preprocessors, and specifically Sass. This article will cover basic concepts and installation. Future editions in the series will cover beginner, intermediate, and advanced Sass topics, where I'll share features and concepts supported by real-world examples. By the end of the series, I hope to have filled your brain with enough Sass knowledge that'll you'll love me forever and possibly send me cupcakes and root beer.

I think CSS on its own is pretty fantastic; but as large websites and complex web applications are becoming more common, the size and complexity of stylesheets is increasing. Add to that an ever-changing (albeit slow at times) declarative language that's also growing in complexity, and things start to get a bit unwieldy. Say "hi" to multiple vendor prefixes and specs (I'm looking at you, Flexbox) that continually change or take a while to be finalized.

This is where a preprocessor can really help. A preprocessor enables you to do things such as:

• use variables to store values that can be reused
• nest your CSS declarations
• separate preprocessed CSS out into separate files for easier maintainability, while still concatenating everything out into a single CSS file
• create mixins that let you reuse common snippets of CSS
• keep your preprocessed CSS dry, meaning you don't repeat yourself
• improve maintainability with larger projects and teams

Since web browsers can only understand CSS, a preprocessor will give you the benefits of what's listed above, work some magic, then spit out a CSS file that the browser can understand.

There are many CSS preprocessors. LESS, Stylus, and Sass are the most popular. Personally, I prefer using Sass. The primary reason I chose Sass is because of my development stack. The majority of the web sites and applications I work with are written in Ruby. Sass is also written in Ruby and works really well in a Ruby development environment. If you're building a site or application in Sinatra, Rails, or one of the many Ruby static site generators, then you can preprocess your Sass directly without running extra software or an extra process in the command line.

LESS and Stylus are both great CSS preprocessors built on Node.js. If I were writing Node.js applications, I would choose Stylus. It can be extremely terse and has many of the features that exist in Sass. You could also use LESS, but for me, LESS lacks many of the features that I've gotten used to through writing Sass. For a detailed comparison of the features in LESS and Sass, you can read Chris Coyier's blog post on the topic.

There's been a lot of excitement about preprocessors over the past year. Many people are just hearing about them for the first time. Preprocessors aren't new, especially the CSS ones. Sass has been around since 2006, which in "web years" seems like an eternity. Hampton Catlin is the original creator of Sass (and Haml, an HTML pre-processor). Nathan Weizenbaum later took over the project. Not too long after that, Chris Eppstein joined the project, and the two have been maintaining it since.

You can keep tabs on either of them to find out about current or future updates to Sass.

NOTE: I'd like to quickly point out, it's always "Sass," never "SASS" or "SaSS". Failure to use the name correctly could result in either Chris, Nathan, or Hampton appearing at your doorstep.

Sass

When Sass was originally created, there was a single syntax, Sass, also called the indented syntax, with the file extension .sass. The Sass syntax was created to be more terse and legible and enabled you to write CSS without using ; or {}. A "gotcha" (or feature, depending on how you look at it) is that it's white-space dependent. This means that you can't mix tabs and spaces for indentation, as Sass forces your indentation to be consistent. Overall, it's fantastic, terse, and I love it. A simple Sass would look like:

SCSS

Later, a second syntax was introduced, referred to as "SCSS" or the "Sassy CSS" syntax, which uses the file extension .scss. This syntax is the favorite of developers or web designers that are just starting out. It's written just like CSS, is easier to adopt, and doesn't depend on indentation to keep it happy. An example of SCSS would look like:

The SCSS syntax is also preferred by many because you can take a plain CSS file, change its file extension from .css to .scss, and you automatically have a valid SCSS file. This is a very quick way to start converting over an existing website to Sass.

Both the Sass and SCSS versions of the code would be compiled to normal CSS, which would look just like this:

Using Sass has become pretty darn simple over the years. The two most popular ways are:

1. installing a GUI app
2. using the command line (gasp!)

GUIs galore

A GUI lets you get up and running by using a nice, pretty application. By far the most popular is CodeKit, which is available for Mac. Codekit makes it easy to start a new project or convert an existing one. It'll automatically take your Sass or SCSS project and compile your CSS for you.

A few other GUIs that might interest you:

• LiveReload
• Scout
• Compass App

If you happen to be on Windows, it's easy for you, too, since both Scout and Compass App work on Windows.

If you're on Linux, then Scout would be your best option for a GUI.

The Beloved (or Dreaded) Command Line

If GUIs just aren't your thing or you don't want to spend the cash, then you'll love the command line. There's a tiny bit more work involved, because it requires having Ruby installed and the Sass gem. I'll break it down by operating system.

OSX

If you're on OSX, then you're in luck. Ruby is installed by default. To install Sass, you simply need to open up your favorite command-line interface. Terminal comes installed as the default. In the command line simply type:

If you get an error, more than likely you'll just need to install the Sass gem using the sudo command:

Linux

If you're using Linux, I assume you already know how to use package managers and get around the system via the command line.

First, you'll need to install Ruby. You can install from source or use the apt package manager on both Debian and Ubuntu. For brevity, I'll just cover using the apt package manager. In the command line, type:

Once you have Ruby installed, you can then install Sass. Again, in the command line, type:

Windows

In the Windows world, folks have gotten pretty clever getting Ruby installed. The easiest way to get Ruby running on your Windows machine is to use RubyInstaller. Make sure that the checkbox "Add Ruby executables to your PATH" is checked after you open the installer.

Once you have Ruby installed, open up your command prompt and type:

Compile like a madman (or woman)

Now that you have Sass installed, you're ready to generate some CSS. Assuming you've already changed directories via the command line to the project you want to work on, you'll need a .scss or .sass file to compile. Say, for example, I have a SCSS file called 'base.scss'. In order to convert that file to CSS, type the following in the command line (it'll be the same, regardless of the OS you're using):

In the command line, you're simply telling Sass to take your base.scss file and compile it to base.css.

I think it's a pain to have to type that every time you want to convert a Sass or SCSS file to CSS. The Sass folks think it's a pain, too; so they created a watcher that will automatically compile your SCSS or Sass file to CSS as you make changes. You can run the watcher in the command line by typing:

Notice the ":" separating the two files. Don't forget it.

Instead of just watching a single file, you can also watch an entire directory of SCSS or Sass files by typing:

Assuming you have two folders, /sass and /css in an /assets directory, this will watch for any SCSS or Sass file in the /sass directory and compile the CSS equivalent into the /css directory.

Over the years, as the popularity of Sass has grown, so have the misconceptions. I'll squish a few of the most popular ones that I've heard:

1. I have to know Ruby to use Sass.

False. It's written in Ruby, but you don't have to know Ruby to use it.

2. I have to install Ruby to use Sass.

False. You can and probably should use a GUI. There are a good many outlined in this article. If I had to choose a GUI, I'd probably choose CodeKit. It is truly glorious.

3. I need to know how to use the command line to use Sass.

False. I prefer to use the command line and think it's the best GUI out there for development, but you don't have to use it. Again, use a GUI.

4. Using a pre-preprocessor will bloat my code.

Partly true and partly false. It really depends on your understanding of CSS and how much time you spend learning a preprocessor to produce code that looks like how you would write it by hand. Mixins and nesting tend to be two of the biggest "gotchas" for developers new to using a preprocessor. It's important that as you get started, to review the code that's generated from the preprocessor. Later in this series, I'll go over how to use the features of Sass effectively to prevent code bloat and produce fabulous CSS.

5. I hear debugging can be a pain

   False. Debugging Sass has gotten a lot easier over the past few months thanks to browser developers. There is a great Sass Inspector available for Chrome v22 and above. Sass Sleuth is available for any WebKit browser. Experimental Sass support is also currently available in Chrome Canary developer tools. It's getting much better.

The first time I tried to use a preprocessor, it was pretty rough and I didn't know what I was doing; but once my brain caught on, I was able to rock and roll. I encourage you to give Sass a try. If you want an easy playground to test the various syntaxes without having to buy an application or poke around on the command line, then definitely try CodePen. CodePen offers you the ability to write Sass or SCSS code, see how it will work, and even preview the generated CSS, all from within the browser.

Up next in this series, I'll talk about some of the basic features of Sass.