The “dark sides” of LESS (and probably SASS)
LESS and SASS – two akronyms that are very popular these days. These preprocessors seem to, no they sometimes are even praised to be the saviors of CSS. Mixins, variables, nesting, math functions … All of that sounds great, like very useful additions for your everyday work with stylesheets. Well, they can be kind of useful, I can’t deny that. But …
I’ve tried out LESS recently at a small project and first it got me very excited. The possibilities seemed endless, the benefits overwhelming. First I started to rearrange and rewrite my stylsheet by nesting and indenting the proeperties nicely. It took me quite some hours and everything was nicely structured then. But! Yes, there’s the first “but” (and more to come). LESS doesn’t allow you to group selectors with the colon (),) like .myClass1, .myClass2 {[some CSS properties]}. I was very disappointed when I found out but managed to get over it.
Sorry, I’ve written complete bullshit here. Please reference to the following paragraph for the actual problem.
I’ve tried out LESS recently at a small project and first it got me very excited. The possibilities seemed endless, the benefits overwhelming. First I started to rearrange and rewrite my styelsheet by nesting and indenting the properties nicely. It took me quite some hours and everything was nicely structured then. But! Yes, there’s the first “but” (and more to come). LESS doesn’t allow you to group selectors (with the colon combinator ,) in a certain way.
Let’s say we have defined the following rule: .myClass1 .mySubClass1 {[some CSS properties]}. But shortly after that we realize that there is another rule, let’s say .myClass2, with the exact same properties like the former. So in vanilla CSS I would just write .myClass1 .mySubClass1, .myClass2 {[some CSS properties]}. But unfortunately that’s not possible in LESS. Because this way LESS assumes that you want to prefix .myClass2 with .myClass1 and so it ends up like .myClass1 .mySubClass1, .myClass1 .myClass2 {[some CSS properties]} in the generated CSS (see more in the comments).
I was very disappointed when I found out but managed to get over it. To reference to the sample above: I mixed in the first class into the second class like .myClass2 {.myClass1 > .mySubClass1}. Unfortunately this way the properties get repeated, which isn’t the case when you combine selectors in pure CSS. Since the HTML structure was already finished and couldn’t be changed anymore I wasn’t able to create a completely new class with the given properties and add it to the desired HTML elements. A big letdown for me, especially when I want to “convert” exisiting CSS files into LESS files.
After that I wrote some mixins (which are especially useful for gradients and border-radius or to reuse other code blocks) and applied a few color functions. But! Yes, here comes the next “but”. Although my stylesheet was not too long it already took me some effort to figure out which level of nesting I’m currently in, which parent a certain child selector belongs to. And I also couldn’t use tools like Chrome’s code inspector (which I quite adore) anymore, because everything the browser sees is a compiled CSS file, there is almolst no connection between the LESS and the compiled CSS file. That also leads me to my next concern about LESS. But! Yes, the next “but”. The compiled CSS code can get pretty bloated, especially with heavy usage of mixins, that means the reuse of previousely written rules/properties. Of course, since such a mixin just gets copied and inserted. I like to do such reuse by grouping selectors (like described above), which LESS doesn’t allow me to in certain circumstances. Maybe I can overcome that with a better planning (like promoted by SMACSS or in Harry Robert’s recent article), but it still is a pretty big letdown for me.
Although I haven’t tried out SASS yet, I know that such functionality is handled better there with @extend. It doesn’t simply copy code blocks but is capable of renaming and inserting completely new selectors – which would be my personal saviour. However the biggest problem for me with CSS preprocessors is the fact that they are only “masks”, kind of “curtains” for your vanilla CSS. They don’t solve problems, they just hide them away from you. Because in the end it’s still common CSS, not more, not less (what an irony to use this word here). Oh, and there is the problem that LESS uses the @ sign for curtain functionality which can and will lead to problems with @font-face and media queries, especially if you want to “mixin” them.
Apart from that there surely are a lot of benefits and I really don’t want to slam LESS (or even SASS). It just doesn’t work for me right now. Maybe it will for you, I really hope so and if you are interested to learn it I really want to encourage you to do so. There are a ton of tutorials (even at the official website) out there, so you won’t read any best practices here. My intention is to show the “dark sides”, the aspects that seem to be overlooked by the people. I’d really be pleased if you share your experiences in the comments, what you think about LESS and SASS, how you use it and what you love about them, but also what you really hate.
