Writing CSS can be tedious. Period. I have been doing web development for over 10 years now, and yet sometimes dealing with a CSS compatibility issue still can give me more heartburn than anything else. With the amount of trouble you can go through with browser compatibility alone, why make your life more difficult by writing all your CSS by hand?
You need a CSS preprocessor.
Most of you are familiar with what a CSS preprocessor does, so I won't go into the details of what they do. But, let's go into all of decisions/thoughts that drive me to recommending Sass as my daily driver.
So which preprocessor do you use? LESS, Sass or Stylus? I work with and coach many web developers at my job, and the flavor of choice that I have seen over the last few years is Sass. I don't think I have seen anyone develop in LESS at all, and I can count on one hand the amount of devs that fire up Stylus as their day-to-day. With that said, I tend to go with what I see the market trending with since I don't see any show stopping differences between them all. Since I am focused on creating front end architecture for projects where code could be passed off to other developers and even other companies quickly, I continue to choose Sass because of its popularity.
However, just because someone says they are using 'Sass' in their project doesn't give you the whole picture. I recently had a .Net developer say that the CMS we were using could handle all the .scss compiling because it was using Sass, and our workflow could be simplified. While his gesture was sincere in wanting to help out with the build process, in the end, that version would cause some issues. More on that later...
Choosing Sass seems like it should be the only commitment that you need to make when choosing a preprocessor. However, that is only the first step. There are several ways of running Sass, and all of them have their advantages and disadvantages. Not only can you choose what framework to run on top of Sass, but you can also choose how you want to run Sass, including which binary to execute against. Let's go into these options for a bit...
After you install the Ruby Gem for Sass, you can be up and running. So in theory, you can just start banging out nested classes and mixins with little setup. But, as all of us front end developers know, using a tool should never be that simplistic. We need more layers to add to our projects! Say hello to Compass.
Compass was the first way I got into running Sass a long time ago. It has some great mixins, and it's ability to create sprites was easy to add into your workflow. All the cool kids were using it, so it just naturally found its way into many projects. Dropping in a simple config.rb to setup your paths in your root directory, and running 'compass watch' in your terminal was dead simple. Plus, that configuration was easy to commit to your version control system so other devs could get up and running without the need of Grunt or Gulp. With all the power that comes with Compass, there lies one big problem...speed. Waiting on your .scss files to compile during your Grunt task was painfully slow. Slow enough to cause you to start drinking...Bourbon.
Bourbon definitely can take the edge off (in more ways than one). Bourbon runs noticeably faster than Compass, since it is just a lightweight library of mixins. While it is installed via a Ruby Gem, the logic itself is all contained within .scss files. Instead of another Ruby process like Compass to execute logic, all you need to do is include the Bourbon files and run Sass like normal. Some of Compass' mixins can easily be replaced with using Bourbon's (in some instances, the mixin names are even the same). If you need some more typography mixins, variables and functions you can add in another library like Bitters to help fill the gaps. So, unless you need all of the functionality of Compass, Bourbon seems to be the clear choice.
However, some people are not a fan of having to add Ruby to their already complex build stack. As I hinted to earlier, developers came up with writing a Sass compiler in C called LibSass and it is currently being used in one of our .Net environments. Not only does this remove the requirement for Ruby, but it also compiles MUCH faster. This can be thrown into a node.js build script using node-sass. Sounds like the perfect fit, right? Well, not exactly. While LibSass might have the edge in speed and portability, it lacks in functionality. Since it is a port, it has often been behind in features compared to the Ruby version, and those minor differences could end up causing headaches for teams depending on it. For instance, running the latest build of Bourbon with LibSass causes errors, due to C version discrepancies on functionality needed by Bourbon's mixins. However, it was recently announced that Ruby Sass is going to wait for feature parity with LibSass before moving forward and will then try to be maintained at the same speed. This is huge news, and will help out the Sass community. It will also get server side developers interested in adding it into their workflow as well since they can avoid the Ruby stack altogether.
So, where does that leave me with my current workflow? It's easy to install LibSass with Homebrew, and then wire that into my Gulp flow. However, the ability to have a nice library like Bourbon that stays fairly updated in my workflow outweighs the pure speed gain of using LibSass. So, it looks like Ruby Sass + Bourbon will be the preprocessor stack that I recommend for the time being until LibSass catches up. Then, I have a feeling a lot of people will start making the shift, including myself.