For Your Consideration: CSS Preprocessors (SASS and LESS)

We’d been hearing the titles for months, and Oscar buzz had definitely started to heat up.  The cast was made up of many familiar names, but it was the newcomers that were generating the real heat.  The big question was: were we in store for the recognition of a giant cultural event or would it be more like 1999′s winner “American Beauty” which seemed like such a no-brainer at the time, but in hindsight was really kind of awful?

Clearly, it was time not only for me to get off my rear and go see “Silver Linings Playbook,” but for Beaconfire to take a serious look at the world of CSS Preprocessors (SASS and LESS), and determine how it could benefit our projects and clients.  Fair warning: This is not an in-depth “SASS vs. LESS” post (though there will be a bit of that as well), I’m mostly hoping to show some of the decision process that helped us decide whether to use a preprocessor at all.

Some right up front (huge) selling points for the Front End Developers in the shop were obvious:

  1. Variables in CSS (should be part of CSS anyway)
  2. Nested Rules (should be part of CSS anyway)
  3. Selector Inheritance (should be part of…hey wait a minute, I’m starting to see a pattern here)
  4. Shiny!

Of course, there were also some things we needed to look out for:

  1. Technology requirements and impact on development?
  2. Increased time to build templates?
  3. Will there be a negative impact on our workflow?
  4. Would we make the switch only to have this turn out to be a flash-in-the-pan?
  5. Increased complexity for us and for clients who may be taking over management of the site

The first step was to review the two preprocessors in contention for the statue: SASS and LESS.  It’s a slightly unfair comparison because, while both SASS and LESS process your files into flat CSS for deployment to your website, SASS opens you up to being able to use Compass, a framework that greatly extends the capabilities of SASS alone.  This means that there are a bunch of things that you can do in shorthand that Compass completes for inclusion in the resulting stylesheet.  Here’s a very basic example:

I type:

@include border-radius(4px);

Compass saves me a lot of typing by writing out:

-webkit-border-radius: 4px;
-moz-border-radius: 4px;
-khtml-border-radius: 4px;
border-radius: 4px;

You can certainly write your own “mixin,” or use a mixin library with LESS and accomplish much the same thing, but it’s hard to beat Compass for a ready-to-go library.

Of course, both SASS and LESS have different technical requirements which may help decide the case for you.  That’s how it really was for us to some extent.  Most of our projects are built on Linux/Apache servers, so installing SASS and Compass as a Ruby gem and just firing it up to watch for changes to our SASS files on the server was simpler than the node.js based LESS method.  Both allow for client side compilation at time of page load and, though it’s the easiest way to get started with either SASS or LESS, nobody here liked that option.  The time required to get SASS up and running on a LAMP server is just a few minutes following these steps.  LESS is equally simple.  You’ll have to decide which technology is best for you.

Then there was the question of syntax.  Having already decided on SASS over LESS for a few of the reasons mentioned there was one more choice to make: SASS or SCSS syntax.  While, at first, we did like the indenting magic of SASS, we decided that it was a bit too fragile for our workflow where many hands may touch the file.  SCSS would also allow us to just drop in a plain vanilla CSS file and update it to SCSS as we wanted, providing for a much more forgiving learning curve.

Of course, this is all based on research we did a few months back which we’ve yet to repeat.  Given how new this stuff is and how fast things change, I wouldn’t doubt that some of the conclusions we reached are no longer valid.  Chris Coyier has a much more in-depth comparison of SASS and LESS you should definitely read.  His post helped us a lot in our decision making process.

We’ve now used Compass/SASS on three site builds and, as far as development time and workflow, the impact has been mostly positive.  We’ve certainly added a bit of time as we get familiar with how best to take advantage of what SASS and Compass have to offer, but in nearly every case, the shortcuts that Compass and SASS offer reduce the time we spend coding CSS.  Tag-teaming in each other’s files has been pretty simple and most of the difficulties that have cropped up are not unique to SASS.  And as far as complexity of handing off sites to clients, we are able to deliver either the entire SASS/Compass bundle for them to manage, or the generated, flat, CSS file.

Since switching to SASS, occasions where I have to work in an old fashioned CSS file have become a real drag.  The advantages are really overwhelming.  It’s a near certainly that we’ll continue to use preprocessors for all of our site builds that allow for it.  We do still work with some systems where we don’t have the access to the server or flexibility in codebase that we’d need to do so, but for the systems that do: we’re sold!


Are you excited about the epic stuff you just read?

Are you smart, motivated, and eager to solve problems in a collaborative environment? If so, we want you! Join our team!

See Our Current Career Opportunities