Getting Started with Sass and Bourbon

In this article, I hope to get you started with precompiling, or preprocessing, your CSS by showing you how to install Sass and Bourbon, and discussing how to make these tools part of your workflow.

I’ll also point you to a few learning resources along the way, so you can take this knowledge and start exploring the potential of this powerful approach to CSS development.

What’s Wrong With Plain CSS?

If you love CSS as much as I do, you have to know that you’re one of the very few of us out there. For me, the power and versatility of CSS is a delight, and there’s a physical thrill I get when I manage to solve a tricky cross-browser display issue or sidestep resource-intensive JavaScript routing with some elegant little CSS animation.

But people who aren’t as enchanted with CSS as you and I have some legitimate complaints. For example, it can be difficult to keep track of the inheritance of properties across elements with differing weights and positions in a growing CSS codebase. There are no variables to support making a universal change that needs to be referenced in multiple places. And it’s often necessary to create redundant code that’s difficult to maintain just in order to make a design work consistently across different browsers.

For me, the most elegant approach to dealing with problems like these and other similar ones was created by Hampton Catlin, and open-sourced so the entire community could help it grow. I’m talking about Sass, a preprocessor for CSS that lets you write clean, maintainable, structured code that generates efficient and useful CSS.

And since Sass supports the ability to write new and original extensions, it’s much easier for developers to come up with their own enhancements. One of the ones I turn to first is a Sass library called Bourbon. While Sass provides a versatile tool set to precompile CSS, Bourbon builds on top of that with enhanced Sass functionality that makes it even faster and easier to write clean and compact code that’s easy to maintain and share.

Using Sass

There are several ways to get started with Sass. You can install the Ruby gem, use a development kit that includes Sass (like the Mac app CodeKit), or take advantage of the LibSass library for native compilation performance in a language like Node or C.

Once you have Sass installed, the basic workflow is to write your CSS using the Sass language, and then compile that into regular CSS that any browser can read and understand.

Installing Sass

The method you use to install Sass is a personal choice, and it will largely be based on your preferred development workflow and your overall skill level. Ruby is one of the most convenient ways to run Sass. I use a Mac, as I’m sure many front-end developers do, and that means I have Ruby pre-installed. So I’m going to assume you have Ruby installed and are running your commands in a terminal on your workstation. (There are excellent guides to installing and running Ruby in different environments and if you’re on Windows, you review this article to help get set up.)

Once you’re in a terminal, and you’ve verified that you have a stable release of Ruby 1.9.3 or later installed, you can issue the following command to get the Sass gem installed:

gem install sass

Then you can make sure Sass is working by issuing a version check for Sass:

sass -v

This should show you that Sass is installed and running, and tell you what version you have. Anything higher than 3.3 should work just fine for this tutorial.

Sass Basics

Using Sass manually is as simple as passing the file name of a .sass or .scss file that contains some code written in Sass to the sass command, along with a destination where you would like the compiled CSS to go. For example, open your text editor and write the following in a new file.

.special
    background: #990000
    p
        color: #ffffff

You’ll see that this kind of looks like CSS, but it’s minimal. Instead of curly braces, .sass syntax (which is the old, but still valid, Sass syntax) uses nested indentations. The nesting of the p selector inside the .special selector indicates that the color will be applied only to <p> elements that are children of .special elements.

You can use either tabs or spaces, but be sure to keep the indentations consistent. Sass using the .sass syntax is particular about indentations. Since Sass uses the formatting of the text to reflect the level of nesting for selectors, it will not compile correctly if there is an extra space where it’s not expecting one to be.

Save the file as ‘test.sass’ in your current directory. Then run the following command at the command prompt:

sass test.sass test.css

This should generate a test.css file in the same directory with a plain CSS compiled version of your Sass code, which will look something like this:

.special {
  background: #990000; }
  .special p {
    color: white; }

You see what Sass did there? In addition to adding the curly braces and semicolons, Sass interpreted the nesting of that p element inside the .special selector and created a new selector limiting the property definitions to only p elements that sit inside an element with a class of “special”. The formatting may be a little funky, but any browser will interpret this CSS correctly. (And yes, there are different ways you can instruct Sass to format your CSS output.)

Choosing a Syntax

The minimal syntax of native .sass files is nifty, but it isn’t mandatory. After Sass was introduced, a new syntax was developed that allowed developers to write their precompiled code in a more familiar CSS-like syntax called SCSS (Sassy CSS). The same code we used before could have been written this way and saved in a .scss file, and the Sass compiler would have treated it the same way:

.special {
    background: #990000;
    p {
        color: #ffffff;
    }
}

So this code could be saved as test.scss, and sending it through the Sass compiler would result in functionally identical CSS to that generated from the test.sass file.

With the .scss syntax, unlike the .sass syntax, the indentation is optional (although it is still useful in order to make your code easier to read). The option to write in the .scss syntax (which allows regular CSS) improved the learning curve and helped make Sass so popular among web developers.

Automatically Compiling to CSS

Nobody developing a web page wants to have to remember to go and compile their Sass into CSS every time they make a tweak to the styles. To help make this cumbersome process more convenient, you can give Sass a set of preferences defining where you want your CSS files to be generated, and set it up to run in the background and “watch” your directories of .sass and/or .scss files, compiling them into native CSS automatically every time you save a change.

While in the same directory where you have your test files from before, try issuing this command via the terminal:

sass --watch test.sass:test.css

Then go into your test.sass file and make a change, like this:

.special
    background: #990000
    p
        color: #ccccff

Here the color value has been modified. You should almost immediately be able to view your test.css file and see the updates reflected there:

.special {
    background: #990000; }
    .special p {
      color: #ccccff; }

You can also pass a set of directories to the --watch option, and all the files inside those directories will be managed automatically.

Once you have Sass installed and running, you will benefit from a number of very useful Sass features that can enhance your CSS management. Beyond the flexibility of nested syntax, you get variables, calculations, conditional expressions, imports, extends, inheritance, and a wealth of other features and functions.

Sass has become a very popular preprocessor for CSS, and in addition to a very thorough documentation site, there are lots of great tutorials about how to get started using Sass.

But you don’t have to limit yourself to basic Sass….

Mixing in Some Bourbon

One of the things that makes Sass so powerful is the extensibility it offers. Once you have Sass in your project, you can build your own mixins to simplify your personal workflow and automate tedious and repetitive code. A creative developer can make Sass support the most convoluted or the most elegant approach to CSS design.

Building a library of custom tools for Sass can be both practical and fun, but there are some obvious conveniences that you may not want or need to create from scratch. Happily, a number of libraries exist to help support Sass developers. One of my favorites is from the friendly folks at thoughtbot, who have provided all of us with with a lightweight extensible plug-in library for Sass called Bourbon, which provides a wealth of basic tools for you, all written in Sass.

Where Sass leaves off, Bourbon fills in with features such as cross-browser vendor prefixing, mixins for advanced CSS features such as animation and border-image properties, functions to do calculations including gradients and color tints, and add-ons such as font-family and button styling. Bourbon also supports custom global compilation settings so you can fine-tune the way it behaves in your application.

Installing Bourbon

Assuming again that you will be working on the command line with Ruby 1.9.3 or later, and Sass already working, installing Bourbon is almost as simple as was installing Sass. Just type the following command to add Bourbon to your system:

gem install bourbon

To see Bourbon working, make sure you’re inside the same directory as your test files from above, and type the following command:

bourbon install

This will create a sub-directory with all the core Bourbon files. You should treat this sub-directory as a third-party library, meaning that it is a bad idea to go in and modify the files inside. Instead, you should import them with Sass and then play with the powerful tools they provide in your own code.

If you left the sass --watch test.sass:test.css command above running, you may notice that doing this didn’t trigger any updates to your CSS. That’s because Bourbon is a library for Sass that needs to be called directly from your primary .sass or .scss file.

To import Bourbon, just edit your .sass file to look like this:

@import bourbon/bourbon
.special
    background: #990000
    p
        color: #ccccff

This time, when you save, you will see the Sass code recompiled. But the output CSS will be exactly the same. That’s one of the advantages of Sass and Bourbon; you can import the entire library and nothing changes about your code unless you explicitly invoke some of the special Bourbon functionality.

Your First Bourbon Mixin

Sass lets you define native functions called mixins, which can take arguments. You can invoke them in your Sass code with the @include directive. Bourbon does some of its magic by including a nice assortment of predefined mixins. For example, one of the great features you get for free out of the box with Bourbon is the ability to generate browser-specific CSS prefixes without all the duplicate code.

With Sass and Bourbon, you can apply a simple mixin to add browser-specific support for more advanced CSS features with a single line of Sass:

@import bourbon/bourbon
.special
    @include linear-gradient(#990000, #000000);
    p
        color: #ccccff

Your updated CSS file will now have a few extra lines, reflecting the extra work Bourbon did to help make your linear gradient background support vendor prefixes, and degrade gracefully for browsers that don’t natively support CSS gradients:

body {
  background-color: #990000;
  background-image: -webkit-linear-gradient(#990000, black);
  background-image: linear-gradient(#990000, black); }
  body p {
    color: #ccccff; }

Learning More

At this point I’ve shown you how to get Sass and Bourbon installed, how to compile your Sass files into CSS, and how to import and take advantage of Bourbon’s complementary functionality. The next step is to dig into the documentation for Sass and for Bourbon and see what features each offers that could streamline your workflow and enhance your productivity.

There are also a number of excellent resources online for learning how to use Sass on a daily basis, including the examples from Sass gurus like Hugo Giraudel, resources like The Sass Way, a weekly newsletter, and an active Sass community with conferences and events where you can learn more. There’s even a great book by Dan Cedarholm called Sass for Web Designers that’s a great way to get started or build on what we’ve discussed here.

There aren’t as many online resources covering Bourbon, but you might want to check out this video and the Thoughtbot website, which demonstrate the depth and power of this amazing library.

The combination of Sass and Bourbon is a powerful toolset to add to your repertoire, and I haven’t even touched on some of the optional Bourbon enhancements such as Neat and Bitters. If you’re curious, leave me feedback and let me know what you would like to know more about.

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • http://www.slatius.nl Arno Slatius

    Thanks for an inspiring article. I didn’t come across bourbon before. Reading through the manual definitely makes me want to try on it my upcoming project.

  • MauriceGriffin

    Been loving Bourbon for awhile now, and with neat, bitters, and now refills, it is quite the toolkit. Been using it as the basis of little “frameworks” for projects at my company. Nice little article to help folks new to Bourbon and SASS get up to speed.

    • KerryJTruong

      Google is paying 80$ per hour! Work for few hoursand have more time with friends & family! On tuesday I got a great new Land Rover Range Rover>>CLICK NEXT TAB FOR MORE INFO AND HELP</b

  • http://r.je Tom Butler

    One problem I find with SASS is that it actually slows down development because it makes tools like firebug less useful. See the line number in firebug? Well that’s not actually the line that CSS is on, so you have to spend time finding the line it’s actually on. There’s a trade-off between writing CSS faster, and maintaining it faster and I’m not convinced that the former is really the better choice for sites which undergo continual maintenance.

  • Jack Saat

    Chris that was news to me as well thanks this will speed up my work flow by a lot!