Less - Pro and Cons

A while ago I stumbled across an older blog post about Less. The post itself was pretty euphoric and kind of reflected the common view of many other blog posts to this topic. The title of the article was "Write Better CSS with Less". Personally I was more interested in the discussion taking place in the comments section below the article. Using Less for about one year, I took this opportunity to sum up my very own résumé on the dynamic style sheet language.

For a start I want to list my personal pros and contras for Less. In my intial considerations I got inspired by some of the comments in the article I mentioned earlier. The basic question of this list should be: Do you write better CSS with Less? Also I want to highlight some of the problems in the daily work with Less. Some of the problems derive from the fact, that Less can't be interpreted directly by the browser. Instead it has to be compiled to CSS. At the same time I want to question some of the statements.

1. The main argument for Less ist the fact, that you will have far less repetitions in your code. This is partially the case, because styles can be merged together easily.

2. The code can be structured more logical, as Less allows nested statements.

3. The code is easier to maintain, because changes could be made globally.

4. Files are easier to read, because there is less code.

5. Global changes can be done more easy, when you use variables.

6. It's easier to automate certain tasks.

1. Because Less has to be compiled, it can be difficult to debug statements from within the browser.

2. Trying to turn a style sheet language into a programming language, doesn't sound as the right thing to do.

3. Mixins are not sufficient for more complex problems.

4. With Less you might create bad performing CSS without even knowing.

5. The combination of HTML & CSS already has a lot of opportunities to reduce duplications.

6. It's hard to name variables.

7. It's not possible to distinguish a mixin from a class.

Personally this is one of my main arguments for using Less. Through the fact that I can define variables, I can change colors later on pretty easy for example.

@color: #FF0000;

body {
  color: @color;
}

However it should be mentioned that with a good IDE, this should never be a problem. Just use "search and replace" on the folder with your CSS files and you can change anything you want.

In this context Less could be really powerful, if you would use different variables for the same color on the base of the use case. This way you could so a partial change. The problem with this might be, that you will get a lot of duplications. Andy do you really want that?

@color-text: #FF0000;
@color-border: #FF0000;
@color-background: #FF0000;

body {
  color: @color-text;
}

#content {
  border: 1px solid @color-border;
}

#background {
  background: @color-background;
}

Another Problem with maintenance or debugging is the compilation itself. LESS has to be compiled to CSS, before it can be used by the browser. Take this nested style set for example:

.content {
  margin: 0 auto;
  a {
   color: @color-text; 
   span {
     display: block;
   }
 }
}

The compiler will output the following CSS code:

.content {
  margin: 0 auto;
}
.content a {
  color: #FF0000;
}
.content a span {
  display: block;
}

Because neither the line numbers, nor the naming matches up any more, you will find yourself struggling to find the right line to edit, when something wents wrong in the browser. Only good commenting and sensible class names, which may even provide information about the nesting, could produce some relief in this scenario. Also you might want to consider splitting your styles into multiple small files on a block or feature basis.

Things get really difficult as soon mixins come into play. Because of bad naming or the code structure itself you might have a really hard time figuring out where the responsible styles are located. Again only clean code and well structured files, can help help you here. You should always assume, that you won't remember anything, when you get back to this project a year later and make things as simple and understandable as possible.

Another problem I came accross is naming of variables. Because the designs tend to have a limited number of colors X and a much higher number of elements Y, where those colors are used, you will get into trouble pretty quickly. What do you name a color, that is used for the headline, the background of a sidebar and the border of an image? Do you name it by the most popular use-case? Than the color would have a misleading name in all other use-cases.

One workaround could be to just duplicate the variables, even if the same color is used and use different variables for headline, background and border. Personally I just gave up on that issue and started to number colors, fonts and similar settings. In most cases you will have to look up the color no matter what, so at least the name doesn't mislead me.

LESS isn't actually easier to maintain out of the box. It takes well structured code, good naming and a certain level of foresight to get the most out of its features.

This is one of the most unpleasant things about LESS. Through the use of mixins and the code gets really lean and this can lull you in. Because the resulting code might get pretty clunky.

Take this snippet for example:

<div class="box box-red-border"></div>
<div class="box box-blue-border"></div>
<div class="box box-green-border"></div>

With a mixin we can summarize this pretty easy:

.box(@color) {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid @color;
}
.box-red-border {
  .box(red);
}
.box-blue-border {
  .box(blue);
}
.box-green-border {
  .box(green);
}

Beautifully clean right? Unfortunately the resulting CSS looks like this:

.box {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid ;
}
.box-red-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid red
}
.box-blue-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid blue;
}
.box-green-border {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid green;
}

Eew, right? With pure CSS this would have been far more elegant.

.box {
  width: 100px;
  height: 100px;
  position: relative;
  border: 1px solid red;
}
.box.box-blue-border {
  border-color: blue;
}
.box.box-green-border {
  border-color: green;
}

Also LESS seems to be really lean, the CSS code produced might be extremely ugly. You should always keep this in the back of your head, when you use LESS. So don't just think about the LESS code, also think about the compiled result. With LESS you don't automatically create better CSS and LESS is not "the better CSS". LESS is only a way to produce CSS code and you should treat the language exactly with this in mind.

One problem for some people seems to be, that LESS doesn't know a difference between classes and mixins. You can actually use both feature in the same way and include them in one another. So some people demand a different syntax for mixins.

Actually I think this is nonsense. First of all: Do I actually need to distinguish between those two? I could actually just a mixin as a class, if I wanted to. Also you could just use a naming convention to deal with it. Name all your mixins with the prefix mixin and put them in a separate file. Problem solved. No syntactic changes needed.

One of the most pleasant features of LESS is automation. Let me give you an example. Lets assume, that we want to create a grid system, where we want to be able to adjust grid widths and margins.

@margin : 10px;
@grid_width : 60px;

.mixin-grid(@size : 1) {
  width: @grid_width * @size + 2 * @margin * (@size - 1);
  margin: 0 @margin;
}

.grid {
  position: relative;
  float: left;
}

.grid_1 { .mixin-grid(1); }
.grid_2 { .mixin-grid(2); }
.grid_3 { .mixin-grid(3); }
.grid_4 { .mixin-grid(4); }
.grid_5 { .mixin-grid(5); }
.grid_6 { .mixin-grid(6); }

And our grid system is finished. If I want to change the width of the grid, I can now just change @grid_width or @margin and LESS does the rest for me. Here LESS is pretty much unbeatable and acts as a valuable extension to CSS.

We started with the question, if LESS lets you write better CSS. And the answer to this question has to be maybe. You don't automatically write better CSS, if you use LESS. Chances are that you actually write worse CSS, if you don't know what you're doing. With LESS it is easier to write CSS, if you comply to some rules. LESS offers some powerful instruments, which can make your life easier, but LESS also has its downsides. This is a result of the fact, that LESS isn't CSS. It is a simplified way to write CSS, with some additional features.

If you are aware of these problems, you can become friends with LESS and make your work a lot easier. And you can actually write some pretty decent CSS with it. I will continue to use it, also I after a year of using it, I am a little bit disenchanted.