FAT

Why Less?

March 8th 2012

Since first open sourcing bootstrap one question Mark and I have heard a lot is: “why Less?” If you’re not familiar, Less is a dynamic stylesheet language meant to extend CSS with things like variables, mixins, operations and functions.

The question is a really good one and something we struggle with a lot ourselves. So much so, Mark asked me to write a little bit about some of the conversations we’ve had around our choice and why we’ve made it.

Going forward, I’m going to try to use this as a faq/wiki for common questions around our decision to use Less. Feel free to ask Mark or I more about any of these questions and I’ll update the post here. Thanks!

Why not Sass?

Sass is great. It ships with rails and has lots of cool, super powerful functionality. That said, we’ve chosen Less over Sass because:

  • Bootstrap compiles ~6x faster with Less than Sass A while back I created a simple benchmark which measured the time it took to compile Bootstrap (written in Less) vs. Bootstrap-Sass (the most popular boostrap port). Our Less version compiled in a little under 90 ms on average, while the Sass version compiled around 540ms.

  • Less is implemented in JavaScript We write javascript everyday, not Ruby. This makes it really easy for us to dive straight into the Less source and patch something if we encounter a bug or help to push a feature forward by doing the development work ourselves and sending a pull request. This has proven to be invaluable and just isn’t something possible for us in Sass.

  • Less is simple At the end of the day Mark and I want it to feel like we’re writing CSS. We love the declarative nature of Less and how much thought has been put into it. While some of the same could be said about scss, Sass is just not our thing.

Why not [some other language/preprocessor]?

We’ve also looked at a few of the other options (like the very cool stylus by our friends at learnboost). However we found that these were either too terse or their feature set just wasn’t a significant enough divergence from Less to warrant us porting all our work over and starting down a new path.

Why not just plain CSS?

This is a really hard one that we come back to a lot (as CSS has a very special place in both of our hearts). However, for now it really comes down to customization and reuse. People seem to like to be able to manipulate variables and get totally different experiences, and we want to enable that as much as possible.

Another interesting data point is that we’ve found our Less styles tend to gzip better than code we’ve written in plain CSS (we suspect because of code repetition). If you’d like to know more about this, you should definitely bug the very talented @necolas about it on twitter!

What about maintaining multiple versions?

We get this question a lot as well, “