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