[nex3]

The article makes it sound like the author expects in-browser processing to be the only way it'll be used:

"Less.js is a JavaScript implementation of LESS that’s run by your web browser. As any JavaScript, you include a link to the script in your HTML, and…that’s that. LESS is now going to process LESS code so instead of including a link to a CSS file, you’ll include a link directly to your LESS code. That’s right, no CSS pre-processing, LESS will handle it live."

No mention that that would be ineffective for a production site. In fact, he claims that live processing won't have noticeable lag, which is just false.

[LaPingvino]

I demand a benchmark. Saying that something is just false without numbers to back it up is not something I have high trust in, and is the start of the gossip that causes internet wars.

First back it up with numbers, then we talk.

[nex3]

Fair enough. I'm running less.js from the command line using node.js on my old-ish MacBook pro:

A trivial CSS file (foo {a: b}) takes about 0.11s. This is probably mostly time spent spawning Node and loading the JS.

The combined CSS for GitHub, about 160K, takes about 1.6s. This is already longer than most HTTP requests.

The doubled CSS for GitHub (the same CSS twice in a row), about 316K, takes about 4s. This is quite large, although there are few sites that have this much CSS.

I tried to run it against the minified CSS for caring.com, but after 2m it hadn't terminated so I gave up. It's likely that this is due to a bug in the implementation rather than slowness.

[cloudhead]

That's because the parser isn't optimized for compressed CSS.

By airing the file out a bit (just adding some double line-breaks), and passing -O2, it goes down to 177ms :)

[nex3]

This is real CSS handwritten by real people. It's not compressed, it's just not in a fully-expanded style. If your parser is slow for reasonably formatted CSS, then your parser is slow. The best case can be as fast as you want, but real-world use is what matters.

For what it's worth, -O2 brings the compile time for github.css down to about 1.5s.

[cloudhead]

The github CSS is compressed. It's fine to test worse-case scenario, but doesn't mean much.

[nex3]

No it's not. Look at it: it's one-selector-per-line, which is a very common style for handwritten CSS. If it were compressed, it would have no line breaks.

[cloudhead]

The benchmark file,

http://github.com/cloudhead/less.js/blob/master/benchmark/be...

Which has all the features of LESS in it, and weighs 94KB (3600loc), compiles in 130ms on my macbook pro.

I would say that's plenty fast. You can try it out by running `$ make benchmark`

[nex3]

It's impressive that your benchmark compiles that quickly. However, as I mentioned elsewhere, the real issue is how fast real-world code compiles. My benchmark uses real-world code, and it's slow.

It's also worth mentioning that plenty of people who care about page load times would still care about 130ms. It's not as glaringly awful as 1.5s, but it's definitely comparable to the sorts of times under discussion. See http://developer.yahoo.com/performance/rules.html and http://code.google.com/speed/page-speed/docs/rules_intro.htm...

[richbradshaw]

As it's cached, it's only the first load that will have the lag. I'd guess it will be quite small as well. If the CSS makes heavy use of mixins and the nesting ability then the lag may even be smaller than the time to transfer the compiled CSS.

Maybe.

[jamesjyu]

First load is where it counts! This is when users first see your site: their first impression. This is an important time that should be kept as fast as possible. Subsequent loads, for most sites, are likely not as important speed wise.

Remember, we have to design our sites as if the user is poised over the back button.