LESS is a CSS pre-processor, allowing developers to use dynamic behavior such as variables, mixins, operations and functions in their CSS code. LESS runs on both the client-side (Chrome, Safari, Firefox) and server-side, with Node.js and Rhino. Source: lesscss.org
I’ve been hearing and seeing a lot of movement in the Australian IT market towards the use of LESS. So a couple of days ago, I thought I’ll give it a try and see if it would be something I would introduce/recommend we use at work.
My first impression is… it looks like a pretty cool language. It’s almost like a proper programming language. It’s got variables, mixins, nested rules, and functions & operations. All help lend a hand to code reuse. i.e. writing less code and more maintainable code. Which is great! It’s a programmers’ dream come true.
But as I began to use the language, I started to see a different light.
I found that I was writing more or less about the same amount of code needed to provide me the same end result as if I had written the code in plain CSS. Thus, I wasn’t getting much benefit from using LESS over plain CSS.
I bet you must be very confused and puzzled and have a question similar to this in your head. “How did you come to this conclusion? Surely it must have made a difference.”
Yes, I agree. It did make a difference. In that with the use of variables, I am now able to reuse bits of generic code – leading to easier maintainability and slightly less code.
But this only occurs in a very few scenarios.
Reason being: We should be standardising our user interfaces with a single simple look & feel throughout the website.
Below is a brief summary of the aspects I looked into that led me to my conclusion.
You should have the same font face types, sizes, and colours for all you content throughout the website/application. So there is no need to pass around variables.
If you find yourself in a position that requires you to override any font styles. You may need to re-think about your HTML markup.
Mixins is a great idea. I really like it. But it’s a double-edged sword. It introduces additional unnecessary dependency. I don’t like dependencies in CSS, because CSS is not program code. You can’t write testcases and run testcases against your CSS rules to ensure nothing is broken when you make a change to the referenced CSS rule(s). If you know of a CSS testing framework that would solve this issue – please get in touch and let me know.
In terms of the Guards I would prefer to use the
@Media queries. This is just a personal preference – I’m a web standards fan. :-)
Nested rules are great for back-end developers who are used to nesting their code. However, I prefer the original CSS way of writing the rules. Purely on the basis that when I come around to debugging the code. I know exactly which rule it is, where the rule is. I don’t need to trace back to the nested rule that generated the CSS rule in question.
This is where I believe the real power in LESS is. However, this is also the point in which I made my decision LESS is not for me. I like a clean separation between program logic, semantic markup, and layout styles. To me I don’t believe LESS fits into any of these categories.
I commend the guys behind LESS. I think it’s a great framework and no doubt it’s had a massive impact on the CSS3 specification. It solves a lot of the shortcomings of CSS2.1.
If you have differing thoughts to mine or I’ve missed something. Please leave a comment.