Migrating from Less to Sass - really a good idea?
Tags: css, sass, less
Published: 2015-10-27 23:00:00

---
title: Migrating from Less to Sass - really a good idea?
published: true
description: Then you think Sass is sassier than Less. Should you move?
tags: css, sass, less
cover_image: 
canonical_url: https://medium.com/@igorsantos07/migrating-from-less-to-sass-really-a-good-idea-2aaa205dcc99
date: 10/27/2015
---

I started my [new project](http://konato.igorsantos.com.br) using Laravel (more on this later), and as it comes pre-packaged with a Gulp helper called [Elixir](http://laravel.com/docs/5.1/elixir) (_facepalm: they misnamed it after the [Erlang platform](https://en.wikipedia.org/wiki/Elixir_%28programming_language%29)_), I decided to migrate the original theme CSS files into Less files.

Why [Less](http://lesscss.org/), you ask? I don't know either. In my last project ([ProtoBoard](https://github.com/igorsantos07/protoboard), now an abandoned pet) I used [Stylus](https://learnboost.github.io/stylus/), although I don't remember the reason as well - probably to use just some of Sass's syntax (no semicolons) without fear of deprecation or the Sass quirkinesses, or maybe because I though I would still need Ruby to compile stuff. Before that, in my old Ruby life, I used to use [Sass](http://sass-lang.com/), but there was no other option at that time besides the defunct TurbineCSS (a project I liked so much I adopted the docs site for years when the original maintainer gave up on it).

Now, after a couple of strong recommendations over Sass, and the fact my stylesheets were taking a whopping ~7s to compile on my 5-years old machine (_Sass has a C compiler, so it must be fast, right?_), I decided to do the migration over to Sass. At this time I still don't heavily use Less features, I have just indented a couple of rules from the original theme, set color variables here and there and add one mixin, so I thought it wouldn't be a painful process.

Indeed, it wasn't. Besides, as said before, some Sass's quirkinesses. I'm probably going to stick with Less, because of the following reasons:

- I use a couple of colour functions, such as `darken()`, `lighten()` and `fade()` from Less. In Less world, they receive a color (hex, HSL or name) and a number, be it a decimal or a percent. In Sass world, however, the lightness functions use percents and the opacity functions (fade-in()/fade-out()) use decimals between 0 and 1; percents and decimals are not interchangeable. *Where are the standards here? I can't see any. _Could you pls decide what type of number for percents you're going to use, Sass? thnx_*

> ![code screenshot comparing Sass to Less](https://cdn-images-1.medium.com/max/800/1*CNvLqBMJgKAaWJQlgLaiRA.jpeg)
> _Mixins: Less vs Sass, using color names as an argument. If you use darken(goldenrod, 20%) in Sass, it will work fine, but by using goldenrod as an argument to a mixin and passing the color name into `darken()`, it yelled a compilation error regarding "color must be a color". Go figure._


- Although functions like darken() can work just fine with color names in both languages, if you pass a color name into a Sass mixin and use it in a function, it's going to yell at you. So what, Sass? *Some arguments are internally changed when they're passed around? WTF*
- It appeared to me that using Sass to compile my CSS gave _whooping_ 100ms of advantage (in a process that takes around 7s). However, running a simple benchmark (below) between branches I could notice Less was actually faster on my machine. In any way, the speed difference is certainly irrelevant.
- Sass actually made a bigger CSS file. However, as I'm running some post-processors as well (namely Autoprefixer and a minifier), the difference would also be irrelevant in production. The size differences are highlighted in the benchmark below as well.
- I felt Sass (at it's mostly accepted SCSS syntax) a little bit more verbose, by having to use `@mixin` and `@include` to declare mixins, instead of using them transparently as classes. That's certainly a matter of taste, though. On the other hand, Less interpolation feels weird - variable: `@var`; interpolation: `@{var}` (?!).
- Sass is more simplistic when you're including another file; [Less allows you to](http://lesscss.org/features/#import-options) simply reference files without actually outputting them into the final file, or force them to be interpreted as Less/CSS. That's quite handy sometimes and might make for leaner CSS files.

In the end, I saw really no advantage on using Sass over Less. Both languages seem to have almost the same features, although Sass seems to be more programmable (not that I see this as an advantage; that thing is still a styling language in its roots, right?). Both languages yield similar results on speed and file size (if minified; but you're always going to compile your files to production, right?). Thus, I'm sticking with Less, as it has a bigger front-end community (I think) and does not play a joke with me regarding percents and (you can judge me here) color names.

If there's any other advantage on using Sass, could you kindly tell me? I found none... _Besides variables being written with the same prefix my project's language (PHP) uses lol_

----------

### Platform details

The tests above were run on a 5-years old machine, a high-end Core2Duo with 8GB RAM (with most of my development applications open). The code can be seen here:

- Sass branch: [source files][1], [compiled CSS][2], [gulpfile][3]
- Main branch (Less): [source files][4], [compiled CSS][5], [gulpfile][6]

And yes, I know, these source files seems to be a mess. They're original from a theme I bought, and there's already [an issue to remind me to merge them together](https://bitbucket.org/konato/web/issues/31/improve-theme-less-file).

----------

Here are the benchmark results, using `gulp` and `gulp --production`. The size indicates the final CSS file size, and the time in bold is the average between the 5 times compilation was run (each value indicated below).

The gulpfiles can be seen in the branches highlighted before, as well as the resulting development CSS files.

> Less (production) - 108.007kb ~ 6.906s
> 6.78s | 7.21s | 6.75s | 6.96s | 6.83s
> 
> Less (dev) - 149.122kb ~ 5.366s
> 5.07s | 5.41s | 5.35s | 5.55s | 5.45s
> 
> Sass (production) - 108.110kb ~ 7.44s
> 7.21s | 7.73s | 7.77s | 7.39s | 7.1s
> 
> Sass (dev) - 151.576kb ~ 5.494s
> 5.73s | 5.27s | 5.24s | 5.67s | 5.56s


[1]:https://bitbucket.org/konato/web/src/34a007329228ff8833091c284c48d2bdcf0603ea/resources/assets/sass/?at=sass
[2]:https://bitbucket.org/konato/web/src/34a007329228ff8833091c284c48d2bdcf0603ea/public/css?at=sass
[3]:https://bitbucket.org/konato/web/src/34a007329228ff8833091c284c48d2bdcf0603ea/gulpfile.js?at=sass&fileviewer=file-view-default
[4]:https://bitbucket.org/konato/web/src/685c92fc520cc40755d7c6360793264349c87bfb/resources/assets/less/?at=master
[5]:https://bitbucket.org/konato/web/src/685c92fc520cc40755d7c6360793264349c87bfb/public/css?at=master
[6]:https://bitbucket.org/konato/web/src/685c92fc520cc40755d7c6360793264349c87bfb/gulpfile.js?at=master&fileviewer=file-view-default