Less CSS performance and implementation

Question

What are the best ways to use LESS for CSS.

• Basically should the Devs write a Less File and then have it compile for production
• Should I link the LESS code and the javascript file.
• Or should I skip the LESS rout altogether and just remake the classes

I am trying to wrangle together some rather sloppy css and want to get control of it before making major improvements. I think it would be very good to have site wide variable so Less seems like a good thing with the variables and nesting.

I am replacing a lot of the background images with css gradients and box shadows so I am also trying to get rid of the vendor prefixes. Sometimes I see what kindof looks like class overload but is it bad to append a lot of classes to an element such as

<div class="comment dark-shadow round-corners"></div>

Rhinoceros

I wouldn't call 3 classes "a lot." – Nerland

Well thats what I am trying to get a feel for how many classes are too many. – Rhinoceros

Also how specific should these classes be. For example .box-shadow .3pxbox-shadow .3px-box-shadow-blue – Rhinoceros

Answer 1

Less is a great styling language. I use it extensively, and it really helps with code maintainability, as well as with speed of writing the styles.

I personally feel that your styles should not be dependent on javascript to render, so I use the less.app to compile all my LESS into CSS. I rest more peacefully knowing that all my CSS is there and that it works correctly before I put anything "live".

If you are interested I have also been compiling a LESS mixin library that can be very useful: https://github.com/jdmiller82/-lessins-

Bubb

I'd now recommend using Codekit instead of Less.app. It is by the same developer, but Codekit adds SO much more, including SASS and coffeescript processing, and much, much more. – Bubb

By the way the less.app is free and you can get it here: incident57.com/less – Conti

Answer 2

I agree with Jonathan, I don't think you should depend on the users browser to render the styles.

I came up with a solution that uses node.js on the server to intercept requests like styles.css and try to find the equivalent .less file (in this case styles.less) and parse it and return it as CSS.

So on your server you would just have styles.less but you could request the URL example.com/styles.css and get the parsed LESS file. That way the integration is seamless for the rest of your application and it doesn't require the user has JavaScript enabled either.

You don't have to be using node.js for the rest of your app either. I did this in a PHP application.

You can read my tutorial here: http://programming-perils.com/155/parse-less-files-on-the-fly-and-serve-them-as-css/

Postimpressionism

Answer 3

I realize this answer is about two years later than the above ones but I think the question is still relevant.

I think there are use cases where compiling some LESS client side is a good idea (provided you aren't supporting IE 8 or below) and you have a use case that validates it. For example, an application I've worked on recently has a customizable, theme-able interface where text colors, etc need to be modified based on whether the background color they're on is light or dark and may eventually need to support the ability for the user to change them and see those changes reflected on the site in realtime. This is a great use case for client side LESS I think. Note that only a small LESS stylesheet is compiled and the rest of the application LESS that's not related to theming is precompiled. I haven't seen much of a perceived difference in performance.

So when you see comments like "you don't seriously think any decent developer uses less clientside do you?", I'd take them with a grain of salt.

Tudela

Answer 4

The way to use LESS for a production website is to compile LESS files into CSS files.

For local development you can have a file-watcher that rebuilds the CSS files for LESS files that were changed.

If you have multiple CSS files to produce from LESS, you should separate them out.

For example, if you have 30 less files and they produce two CSS files a.css and b.css, you will want to separate those two jobs so that you can compile faster. It's faster for developing because you will only compile a.css if you change any LESS files that affect it.

Rematch