The ATL Sass Meetup

Sass from Zero to Sixty

What is Sass

Sass is a stylesheet language that compiles into CSS. It adds features that do not exist in the CSS language yet such as variables, mixins, and iteration. Sass has two syntaxes.

Installing Sass

Our first step for brand new users will be to get Sass installed. Open up the command line, and run:

gem install sass

If that fails, try running:

sudo gem install sass

Success? Check the version:

sass -v

Still having trouble? Look here.

Compiling Sass

Now that we’ve got Sass installed, we’ll need to look at how we want to compile our Sass code into CSS.

Sass can be compiled via the command line, or with a desktop application like Codekit, Prepros, or Scout.

There are also a number of task runners that will compile your Sass for you like Gulp, Grunt, or Broccoli.

For the remainder of this post, we’ll be using Gulp to compile our Sass (and do other CSS related things that will make our lives easier).

In fact, we are going to use Gulp to:

  • Start our local server
  • Watch for changes to our Sass files
  • Check for errors
  • Compile our Sass
  • Add CSS3 vendor prefixes
  • Add minification
  • Write our CSS file
  • Reload the browser

Installing Gulp.js

First, make sure that Node is installed:

node -v

If you need to install Node, you can do that here.

Now, install Gulp.js:

npm install -g gulp

If that fails, try using sudo:

sudo npm install -g gulp

Next, we are ready to set up a new project.

Download the template

First, download the starter template. This template contains:

  • package.json - a list of npm packages that we will install
  • gulpfile.js - a list of tasks that we want Gulp to run for us
  • application.scss - our Sass file
  • index.html - our hello world web page

Now we just need to install all of the npm packages listed in our package.json file.

In the command line, navigate to the root of the starter template, and run:

npm install

That should have created a node_modules folder with all of the npm packages listed in the package.json file.

We’ve just installed:

Now we just need to run:


This will run our default task. This task starts up our server local server, opens the browser, and begins watching our Sass file for any changes.

When there is a change in our Sass file, the styles task will:

  • check our Sass for errors
  • compile our Sass
  • add the needed vendor prefixes
  • minify our code.

Finally, the reload task will reload our browser.

For a look at exactly how this is set up, check out the project’s gulpfile.js.

Breaking down the gulpfile.js is outside of the scope of this post, but if you’d like a good tutorial, check out Todd Gandee’s post - Journey into Gulp.

Some additional Gulp tasks

A few other Gulp tasks that you might consider adding into your build process are:

Project organization with partials

We’ve got a pretty good build process set up, but instead of having one giant Sass file, lets look at how we can better organize our code using Sass partials.

When Sass compiles, it will create a matching CSS file for any file with a .scss or .sass extension. However, if we prefix our file names with an underscore, Sass will not create a matching CSS file.

So, application.scss will get a matching application.css file, but _my-partial-file.scss will not.

We can use this technique to create an organizational structure for our project. We’ll break our styles up into partial files, and then use @import to bring all of the partial files into the main application.scss file.

// in the application.scss file
@import 'my-partial-file-one';
@import 'my-partial-file-two';
// etc


So, what should our structure look like?

I have written an open source Sass Template called css-burrito that will provide a very scalable Sass structure. In addition, it will automate a few tasks for us like adding and removing partial files.

The template contains three directories and an application.scss file to @import all of the partial files.






The libs directory will house all third party library code. Add libraries like Bootstrap, or Foundation, or Bourbon here. By default, this folder contains:

  • _library-variable-overrides.scss - override any third party library variables in this file.
  • _normalize.scss - Normalize v3.0.2


The global directory is where we will keep all of the utility code that will be used across the entire project. It should be organized as follows:

  • _settings.scss - global variables and maps
  • _utilities.scss - global placeholders, extends, mixins, functions, and utility classes
  • _base.scss - global defaults for base level tags like <body> or <p>
  • _layout.scss - global layout styles like margin, padding, or floats
  • _skin.scss - global skin styles like gradients, colors, and box-shadows
  • _typography.scss - global typography classes


The modules directory will ultimately contain the majority of the code in your project. You’ll add new modules as needed based on the design. This directory also contains a _modules.scss file, to @import all of the other modules into the application.scss file.

css-burrito comes with superpowers!

If you want css-burrito to create files and @import them for you, you’ll need to install it as a global npm package

npm install -g css-burrito

Once installed, you can quickly add a new instance of the css-burrito template by navigating to the root of the project and running:

burrito -n [folder-name] [file-name] [path-to-sass-directory]

This will create a new instance of the css-burrito template, and a css-burrito-config.json file.

Once the config has been created, you can update the modules directory in a number of ways.

Add new module partials to the modules directory:

burrito -m (file-name[s])

Remove module partials from the modules directory:

burrito -r (file-name[s])

And list the partials in the modules directory:

burrito -l

css-burrito customization

If you want to rename any of the files, partials, or edit the structure of the template itself, you can make edits to the css-burrito-config.json file. Once the config edits are in place you can generate a customized version of the template by running:

burrito -g

Let’s put this all together!

Ok, so now we have an awesome build process set up with Gulp, and we know how we want to organize our files.

Go ahead and download the starter-template-with-css-burrito.

The gulpfile.js has been updated to watch our new project.

Sassy Patterns

Now that we’re ready, we can finally begin to write some code!

Lets take a look at some useful patterns.

Sass maps

I use Sass maps in all of my projects for two reasons. First, it limits the number of global variable names in the project, and second, they can be iterated over with an @each loop.

To get something out of a map, you’ll use the built in map-get() function. This takes two arguments, the name of the map, and the key that you want to get out.

Play with this gist on SassMeister.

Custom functions

I am not a big fan of typing map-get() everytime I want to get something out of a map. Instead, I like to create a function for each map to get things out for me.

Lets create our own custom function to use with the $colors map. This new function uses the built in Sass function map-has-key(), which takes in a map and a key, and returns true or false depending on if the key exists.

When we call the colors function, we pass in a key, in this case, the color that we want to get out. If the key exists, our function will run a map-get() for us, otherwise, we log a warning and exit out of the function.

Play with this gist on SassMeister.

@each loops

Finally, we can iterate over maps using an @each loop. Here, we are looping through the colors map, getting the $color-name and $color-hex, and creating a ruleset with that data. We need to use interpolation to add the $color-name.

Play with this gist on SassMeister.


Curly Brace Animation

Play with this gist on SassMeister.

Sassy resources

Alright! We’ve learned how to install and compile our Sass, set up a Gulp task to process our styles, create a file structure, and have seen a number of useful patterns. We are now cruising along smoothly at 60mph.

However, it turns out that on this highway, there is no speed limit!

There are tons of really useful @mixins and @functions out there, and lots of people doing amazing things with Sass.

Sass is a powerful language, so it is also very easy to crash and burn.

I recommend using tools like Sassmeister to keep an eye on the CSS that you are outputting.

In addition, take a look at the following Sass Guidelines to make sure that you are writing sane, maintainable, and scalable Sass code.