LibSass is getting more and more popular every day. Not a day goes by without someone claiming they have proudly moved their codebase over to LibSass. Oh, great.
Do you feel a bit lost? Not quite sure what LibSass is, how it works and what the main differences are compared to the original Sass? Well worry not my friend, I have you covered.
What is LibSass?
Before explaining what LibSass is, let's first recap on what Sass is. Sass is a CSS preprocessor written in Ruby. To use Sass, you have to install it as a gem (a Ruby package) on your machine. Then you can interact with Sass either from the CLI (Command Line Interface) or with an application such as Prepros.
Performance
LibSass is a port of Sass written in C/C++. You see, Ruby is not the fastest language on earth. And it turns out to be quite slow when it comes to Sass.
“Ruby is not one of the most performant languages in the world, to say the least.” - Kamil Bielawski
Not being a Ruby developer myself, I cannot exactly tell why; perhaps file writing is not as efficient as it could be, I honestly don't know. But for whatever reason, Ruby Sass is slow and it gets even slower on massive projects.
This reached the point where some people became tired of the performance lag and decided to start writing Sass in C/C++, to speed up compilation times. What they came up with was LibSass.
Wrapper
You can’t really use LibSass by itself: you need a wrapper. For instance, Node-Sass is a NodeJS wrapper for LibSass. It allows you to use Node-Sass to compile your Sass from Node using LibSass underneath.
There is also SassC, Perl-Libsass, PHP-Sass and even Ruby-LibSass, all using LibSass underneath. However these latter examples are not totally up-to-date thus we more commonly use Node-Sass.
To sum up, LibSass is the C/C++ port of the original Sass program written in Ruby. It is meant to be wrapped, like Node-Sass does to use Sass from a Node environment. Main goal: to be blazingly fast compared to the original Sass.
The Difference With Ruby Sass
Okay, so we know what LibSass is. We know that LibSass is intended to be as fast as a robot rainbow unicorn. Good. So why don’t we all use LibSass right now?
The main problem with LibSass is that it lags behind the original Ruby implementation when it comes to features. At the time of writing, LibSass 3.1 is fully compatible with Sass 3.3, however many features from Sass 3.4 are still unavailable. LibSass misses, for example, use of the reference selector (&) in SassScript (the ability to read and update it on the fly with functions and such).
Happily, Sass core designers have decided to wait for LibSass to catch up before moving forward to Sass 3.5 so both versions should soon be synchronized. However, the Ruby version will always be the main version: patches and releases will always land on Ruby Sass first, then get implemented by LibSass.
Which to Choose?
Here comes the moment where you have to decide which Sass engine you want to run: the original Ruby Sass or the brand new LibSass? As with everything in our field, it depends.
All in all, I would probably recommend LibSass because it is generally faster than Ruby Sass and speed is everything in this world. However, if you need Sass to do something crazy that requires new features yet to be added to LibSass, Ruby would be the better choice.
More often than not, you’ll find it’s not a case of choosing a Sass compiler for a new project, but to rethink the one you’re already using so it suits your situation. If you work on medium-to-large scale projects, you might experience a compilation time ranging between 2 seconds and 30 seconds (yes...) with Ruby Sass. It could be worse with logic-heavy dependencies such as Compass.
At this point, you’ll get sick and tired of loosing 25 minutes a day waiting for Sass to compile and you’ll seriously consider dropping some features to gain speed. In this case, LibSass looks like a giant kitten-shaped cupcake while Ruby Sass is more like an old and dry biscuit...
Making the Switch
To help you decide whether or not you can port your entire code base to LibSass, I set up the Sass-Compatibility project. Sass-Compatibility intends to list all major inconsistencies between the different Sass engines (basically Ruby Sass 3.2, Sass 3.3, Ruby Sass 3.4 and latest LibSass). I recently introduced the project at SitePoint, if you want to catch up.
Note: Sass-Compatibility uses SassMeister to run its tests. SassMeister uses Node-Sass to run LibSass. However, Node-Sass is not compatible with LibSass 3.1 yet (though it should be soon), which means Sass-Compatibility results for LibSass look worse than the situation actually is.
Final Thoughts
There we are, folks. I hope this article helped you understand the what and why of LibSass.
We are currently in an odd situation where LibSass is extremely convenient thanks to its speed, but doesn’t provide everything Ruby Sass does so cannot be unconditionally adopted yet. This will all soon settle down when both versions become fully compatible.
Now, since LibSass is much faster than Ruby Sass (and I think no matter how hard Ruby Sass core developers try, it will always be like this), I don't know what kind of future there can be for the Ruby implementation. At a certain point, I don’t think it will make much sense to use Ruby Sass if it's slower, unless it brings something extra to the table. As we say: wait and see.
