Question

I’ve just downloaded Twitter Bootstrap to take a look at an implementation of LESS. My first impression is that LESS seems like a great thing for writing your CSS with, but it breaks the ability to make quick edits based on browser rendering.

Say I have been handed a live site I’ve never encountered before, built by someone else, as poorly documented as they often are, and asked to change the properties of some elements. The website has 2000 lines of CSS and the last thing I want to do is familiarise myself with the lot of it.

Traditional CSS, in the browser window: Inspect Element: Matched CSS Rules: styles.css:1145.
Open styles.css to line 1145 in text editor of choice, make change, test, done.

LESS, in the browser window: returns a Matched CSS rule from a CSS file that is compiled from any combination of (in Bootstrap) 42 different LESS files. No indication from the compiled CSS file which of the component LESS files originated the property. Proceed to search through 42 different LESS files for the appropriate place to make the change.

Therefor, it seems that LESS is really great when you have the time/familiarity with a project to understand it from the ground up- so that you know which variable declares the colour which is called in the mixin to produce a border which is given further properties in a class declaration- but not so great when you are the unlucky developer who has ten minutes to figure out, from someone else’s code, how (more specifically, where) to change the colours on all the borders.

Have I got it all wrong? Is it the case that LESS breaks the lazy, happy browser-end quick-fix strategy, or is there some method to this that I haven’t figured out yet that preserves the quick and dirty workflow?

Answer 1

LESS runs on both the client-side (Chrome, Safari, Firefox) and server-side, with Node.js and Rhino. (http://lesscss.org/). So yes, you can use it also on the client-side.
Just make sure you link your less stylesheets with rel="stylesheet/less and remember to add less.js into your HTML to generate CSS from the less source.

A drawback is that developer tools like Firebug don’t have native support for less. This is the same problem as with CoffeeScript, which has really poor debugging facilities in browsers right now. I’m pretty sure debuggers will evolve to support other JS languages, I wouldn’t be surprised to see similar happening for stylesheet languages like less. However, I wouldn’t hold my breath while these tools make their way to the mainstream.

I share your line of thinking in that while LESS may be a wonderful idea for hardcore CSS development, it also adds a layer of complexity to your development stack. Doing so may not be justifiable on all cases.