Nathan Leigh Davis is a designer and developer who writes about design, technology and things that inspire him.

Journal

My first impressions of LESS

I worked on a job last week that required me to use LESS for the first time and I thought I'd share my impressions. For those that haven't come across LESS before it's a dynamic stylesheet language that extends CSS by introducing principles such as nesting, global variables, mixins and functions. Like SASS it attempts to make the process of writing and maintaining CSS easier.

The good parts

LESS streamlines the process of structuring CSS files because of the way in which you can nest selectors. Essentially this helps write clean and maintainable CSS and for those working in larger teams this is great. It's not uncommon for developers working within these environments to make changes and tack them to the end of stylesheets, because they're unsure how the CSS has been structured. LESS eliminates this problem by enforcing a more structured approach to writing CSS.

Global variables, mixins and functions are also terrific as they reduce the amount of CSS that you have to write and maintain. Swapping fonts, colours etc. becomes a snap because you only have to change a single line of code.

The bad parts

While I can obviously appreciate the benefits of LESS, I think the more structured approach that it enforces can also be something of a negative. I'm a massive fan of adding a classes to the HTML element so I can write CSS code specifically for older versions of IE, browsers without javascript and even touch devices. I tend to write these additional styles inline:

.main .button { // base styles } .ie7 .main .button { // IE7 fixes } .touch .main .button { // Make the button bigger for touch devices } .no-js .main .button { // JavaScript isn't active - hide our button }

The problem with LESS is that you can't do this because of its nested syntax. You have to rewrite everything all over again, which is a massive pain. In addition to this LESS doesn't handle media queries all that well either. This implies that if you use LESS the easiest way to manage this problem is to maintain additional stylesheets, which in my opinion is far from ideal.

This leads me to my second gripe. The final CSS stylesheet that is generated bears little resemblance to the LESS markup, therefore using developer tools such as Firebug becomes a bit tedious. You can't find the line that your editing easily and because you loose the ability to write additional styles inline the whole process of updating code becomes very tedious.

My conclusion

While I can see the benefits of LESS, especially for larger teams, it doesn’t fit the way I personally write and structure my stylesheets. Therefore I think the decision to use it is a largely a personal choice. I found it very inflexible and if anything it made writing CSS more complicated, especially when you start targeting different screen sizes, browsers, touch devices etc. Given the prevalence of libraries such as Modernizr and the popularity of responsive web design it will be interesting to see how long LESS remains popular, given the inflexibility that its nested approach imposes.