Using Sass at Full Power

Part 2 — Setting Up a Scalable Boilerplate


In Part 1 we looked at using some of the more powerful Sass stuff to make our mixins DRYer and better at error handling. In this post I’ll be looking at something that’s a little less technical and maybe a whole lot more helpful to your workflow: setting up your custom Sass “framework”, or boilerplate.

Note: This post relies heavily on Sass’s @import function and the concept of partials. They’re easy to learn, but if you don’t know them I advise you check that out first.

Where to Begin

No matter how close you and I became, dear reader, I would never be able to tell you how to write your own mixins and placeholders. Some people use Compass for that sort of thing, some use more obscure libraries, and still others write their own according to their respective needs.

I’m not going to go through those options with you. Whichever you choose, though, will make up the base of your framework. The point of this post is to see how we can take that base and build on it to create something scalable and easy to maintain. It’ll be easy to set up too, I promise.

Degrees of Separation

With the rise of languages and frameworks like Ruby on Rails and AngularJS, the MVC design pattern has become a more popular one. For those who don’t know, it focusses on the separation of the visual (the view the user sees) and the guts (the model, or internals of a system) to create a scalable system. And that’s awesome, because we’re going to apply some of that MVC goodness to our Sass.

Well, kinda.

Firstly, we need to look at our Sass/CSS and try to separate content by function. You could separate your Sass by pages, making each partial with all the Sass for each page, like this:

—- sass folder
 — _home.scss
 — _about.scss
 — _contact.scss

And so on. But that doesn’t really help us much; the problem is that CSS classes are often shared between pages, so what do we do with a class that’s in the Home page and the About page? Where do we declare it?

My personal solution to this problem was to separate partials out according to function. So we could start with a folder full of partials to handle the background of our Sass work. See below:

-- sass folder
-- base
-_variables.scss
-_mixins.scss
-_placeholders.scss
-_functions.scss

Here we’ve created a “base” folder which contains all our base functionality, our mixins and placeholders etc., from which to work. But what about our CSS goodness? The actual styling for classes and IDs?

-- sass folder
-- base
-- layout
-_core.scss
-_images.scss
-_typography.scss
-_lists.scss
-_nav.scss
-_forms.scss
//etc

Another folder, “layout”, contains the partials for these. The “_core.scss” file contains our base styling, plus any container divs I might have declared, while the other partials contain all the styling for the elements they’re named after.

Remember, you have to think of this in terms of inheritance. Not like prototypal or OOP inheritance, but like “I-got-this-from-my-grandma” inheritance. If your stuff is being used in production, other developers will have to deal with your code; this almost always ends up being a “why is it doing that now” exercise, which in turn becomes an “ah, so this is the bastard element that’s causing issues” (especially with CSS).

By separating out partials by element type, anybody inheriting your code will be able to pinpoint which file the element is contained in and then change it. Got a new element to cater for, like SVGs or a Google map? Add another partial for it. Easy peasy.

Pulling it All Together

Now we have to bring things to a head and import everything into a core Sass file. Check out “style.scss”:

/*========= STYLE.SCSS ========*/

/*BASE  — Base functionality
===============================*/

@import "base/variables";
@import "base/mixins";
@import "base/placeholders";
@import "base/functions";

/*LAYOUT — Partials for elements
==============================*/

@import "layout/core";
@import "layout/images";
@import "layout/typography";
@import "layout/lists";
@import "layout/nav";
@import "layout/forms";

Then we simply compile “style.scss” into our final CSS file and we’re done!


It’s important to note that what I’ve outlined here is just how I approach things. If you think that your own framework needs to take a different approach in its context, then it’s important that you take it. Use what’s best for you. The idea for this was largely based on Cathy Dutton’s approach, but my own needs are completely different and so I’ve changed it (pretty hectickly) to suit them. You may need to do the same.

Note: I have found there are issues with this method of working should you be using Grunt and Sass 3.3 mixins and functions. Compass’s Grunt task, the only one (that I know of) which is able to watch and compile Sass on multiple files and folders, does not support Sass 3.3 as of writing this. Thus, if you plan on using this, it’ll have to be with the Sass Grunt task, in which case you’ll have to either watch the “style.scss” permanently or edit your Gruntfile every time you move to a new one.

Email me when Byron Houwens publishes or recommends stories