CSS Pre-Processor?

While working on a WordPress theme for a client recently I took some time to explore two CSS pre-processors, SASS and LESS. My ‘exploration’ was a little forced because the eCommerce plugin we used, WooCommerce, uses LESS and we needed to change the stylesheets so the package styles were compatible with the rest of the site template.

I took more time than would have been necessary to just alter the styles so I could evaluate the two pre-processor options, and used SASS to create for the theme stylesheet and LESS for the plugin stylesheet. Although it was a pretty small job I came away with some pretty firm impressions of the two languages.

First, they are very similar. Both of them provide for the use of variables, mathematical and logical operators, conditionals, and “mixins”, which are a kind of re-usable library item. There are native mixins for popular CSS3 elements that do the hard cross-browser implementations for you — I used gradients and border-radius a lot because of the design.

Both languages employ a nested technique so the structure of the file resembles the structure of the page DOM, so you write styles that look like:

header {
  font-size: 1em;
  h1 {
    font-size: 1.2em;
    span {
      font-size: 0.8em;
    }
  }
  h2 {
    font-size: 1.1em;
  }
}

Notice that you can put styles for all elements within the header element very easily, simplifying maintenance.

Also, both languages extend the CSS @import feature so that the developer can structure the files for quick reference and them assemble them into a single stylesheet to reduce the number of http requests a page has to make, so making the page load faster. My stylesheets, before compilation, look more-or-less like this:


@import "_reset";
@import "_typography";
@import "_layout";
@import "_menus";
@import "_wooCommerce";

(Beginning imported file names with an underscore is a naming convention required to compile SASS.)

The compiled stylesheet in this case turned out to be over 2200 lines long. Five years ago that would have been hard to troubleshoot and modify, but great tools are around to make adjusting stylesheets a breeze — I’m thinking of Firebug for Firefox, but Chrome has native developer tools that are comporable and IE9 was developer tools that are, well, there. Those good tools and the ability to include CSS comments in the compiled styesheet reduces the apparent complexity a lot. Experiences differ, but I think it’s easier than working with multiple stylesheets being called by the page.

A warning, though: you have to ensure that collaborators do not edit the complied stylesheet directly because it will be overwritten next time it’s compiled, which means that they either have to learn the language you’re using or not touch stuff.

LESS works in a JavaScript environment and SASS in Ruby. That probably doesn’t matter, but out of the box compiling files is done via a command-line interface. I’m not very interested in learing either Ruby or Node.js, so lucky for me there are compilers written by third-parties that simplify that part of the work immensley. Although LESS expects that style sheets will be compiled on page load, that approach provides no benefit for my typical clients, so after development I compile the CSS into a single file and treat it like any run-of-the mill CSS stylesheet.

There’s no reason you have to decide to use one rather than the other. They resemble each another enough so that if you learn to use one you can pick up the other in minutes rather than hours. Right now I prefer LESS — the native mixins worked better on the project I tested things on and I liked the third-party compiler much better. I get the feeling (from reading other developer’s blogs, here and here, for instance) that SASS may be under more active development than LESS but that’s something I’m willing to wait-and-see. It also seems that LESS may be currently more popular, but that’s hard to measure with any confidance.