Do you recommend against javascript based LESS?

Question

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...

Personally I do that kind of stuff at build time, because it's really not that hard. — Pointy, Jun 25 '10 at 00:37
@Pointy - Do you have any examples of what you do? Anything in .NET (I'm building MVC 2.0 based apps). Thanks! — Chaddeus, Jun 25 '10 at 00:51
I would just set up a post-build action that runs the Ruby lessc compiler on your .less files, transforming them to regular .css files. — Dean Harding, Jun 25 '10 at 01:28
sorry no .NET examples - I build in a Java world, and I use Freemarker to pre-process .CSS files — Pointy, Jun 25 '10 at 03:02

Matthew Flaschen · Accepted Answer · 2010-06-25T00:43:51.920

6

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.

edited Jun 25 '10 at 00:43

answered Jun 25 '10 at 00:37

Matthew Flaschen

278,309
50
514
539

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. – Chaddeus Jun 29 '10 at 16:45

score 2 · Answer 2 · answered Jun 25 '10 at 00:38

2

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.

answered Jun 25 '10 at 00:38

Dean Harding

71,468
13
145
180

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 Jun 25 '10 at 00:43
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 Jun 25 '10 at 00:56
4

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 Jun 25 '10 at 01:24

score 2 · Answer 3 · edited May 23 '17 at 10:32

I haven't tried in production, but there may be some interesting use cases around LESS variables. For example, you could change underlying less variables that in turn change a bunch of dependent CSS rules (relative widths/heights for example).

See https://stackoverflow.com/a/8742705/255961 for interesting patch that makes it very easy to change them using a simple modifyVars() function.

With it you could change your Bootstrap grid size and everything that depends on it with a single, local JS call:

less.modifyVars({
  '@gridColumnWidth': 50px
});

Do you recommend against javascript based LESS?

3 Answers3

Linked