When I joined the team here at Planet Argon, LESS was being used to code and compile the current CSS files. When a new client project came along, we started the transition to using Sass. The decision was made to use Sass when it was included in Rails 3.1. Being a Rails shop, we wanted follow the conventions that were being advocated by leaders of the Rails community. The differences between the syntax of Sass and LESS are minor, but the process of transitioning our largest project to SASS has had its issues.
What’s the Difference?
On the surface, LESS and Sass are very similar. Both have variables for reusable bits of code like colors or font declarations. Both use a nested structure to reduce the amount of written code. They also both use mixins that contain full blocks of code that can be reused and can include variables to update certain values of the contained code. For an in-depth comparison of the two, check out Chris Eppstein’s writeup on the subject.
One advantage we found with Sass was in the compactness of its compiled code. For example, consider the following code:
.classname,
.another_classname,
.yet_another_classname {
color: #fff;
}
LESS would compile that code like this:
.classname { color: #fff; }
.another_classname { color: #fff; }
.yet_another_classname { color: #fff; }
Where Saas would compile the same code like this:
.classname,
.another_classname,
.yet_another_classname {
color: #fff;
}
This produced a significant amount of repeated code. This may have been caused by the old gem we were using to compile the LESS code. The current version of LESS compiles via Javascript and may produce similar code that Sass provided us. In any case, with the newly compiled code, we were able to shave a large chunk off of our CSS files.
So the reason to make the switch to Sass was obvious. Better compiled CSS and official adoption into Rails 3.1. Now we just have to do it.
The Transition
The biggest challenge we ran into was the difference in syntax between the two. This included how variables, mixins and reusing classes were written. We had to go through each LESS file and update the syntax to use the SCSS standard. The devil is in the details here and you must remember that the way LESS might handle something without a prefix, SCSS needs a prefix to make the same magic happen. It took us a couple rounds of review to get all the specific markup transitioned correctly, but overall it went very smoothly.
The challenge now is to bring style changes from remote branches made before this transition took place. Unfortunately, there was no easy way around this. Once a branch needs to be staged, we will need to review it and bring over any changes made to the LESS files. This will be a temporary, yet annoying aspect of the transition.
On Guard
With this transition, we also updated the way we compile Sass by using Guard. Guard, and its corresponding gems, are a set of libraries that will watch for changes in the filesystem and perform pre-defined actions when a change is detected. This enables us to simply evoke Guard in the terminal and let it watch for any changes to our SCSS directory. Previously, we were compiling each file individually as we worked on it. Guard has made the whole process of compiling CSS code so much easier.
The Future
Going forward we have our feet solidly placed in the Sass camp. I can’t say that Sass is better than LESS, however, with its ties to Rails 3.1, Sass is a natural choice for us. I suppose the other advantage SASS has over LESS is the cleanliness of the compiled code. In any case, you can’t really go wrong either way. Both will help you write more code with less typing.