views:

89

answers:

2

After I watched this NetTUTs video, I'm very interested in trying out the LESS.js method shown.

Other than the obvious, "What if the user doesn't have javascript enabled?", or "There's going to be a small performance hit"... is there a reason this cannot be used in production?

LESS essentially looks like what CSS should be...

+2  A: 

I can't see any reason why it should be used in production. It makes more sense to run this as a build script, then make the output (regular CSS) available on a cached cookie-free domain. Then, it works fine without JavaScript and doesn't require JavaScript processing (which will be slower than the CSS parsers written in tuned native code) on every page load.

Matthew Flaschen
I'm starting to agree... I think the article is more or less a demonstration of what's "cool", but not was is the most performant.
Chad
+2  A: 

Yes, if people with Javascript disabled is a concern, then I would recommend against the Javascript-based LESS. Personally, I see no advantage in it over the Ruby-based one, since you really only need Ruby installed on your development machine - once you compile the .less file to a .css, there's no difference between a LESS-compiled .css file and "hand-written" one.

Dean Harding
The advantages are the same as any JIT compiled script vs a compiled one. You skip the compiling step. Also LESS.js will cache in local storage (for all browsers that support it).
Alan
??? What overhead will be required for compiling down to CSS?
Pierreten
CSS isn't a programming language, and LESS.js isn't a JIT. Read [the code](http://github.com/cloudhead/less.js/blob/master/dist/less-1.0.22.js). It parses the less and adds style sheets at page load. It doesn't have any real JIT capabilities, like dynamically compiling hot code to native code, because there's no actual code (only styles).
Matthew Flaschen
If you've already got an automated build or deploy (and you *should*) then there's no benefit to "skipping the compilation step".
Dean Harding