Update site to not recommend clientside use of less.js

[paulirish]

Recently saw a comment on Hacker News along the lines of.. "you don't seriously think any decent developer uses less clientside do you?"

.. but I sort of do, especially as that technique is recommended very prominently on the site of less.js

But people are rightly recommending against using less clientside in a real production environment: http://stackoverflow.com/questions/5482682/would-it-be-a-bad-practice-to-use-less-js-in-a-production-site-client-side-javas
http://stackoverflow.com/questions/6105033/less-css-performance-and-implementation

I think less would be wise to recommend clientside use only for development but evangelizing serverside compilation for production.

[ttfkam]

If you're using a 3rd party CMS, have limited control of server side, and don't want to worry about syncing issues with the produced CSS, it's an option. As the stack overflow discussions point out, Less caches the translated CSS in newer browsers. But our site also requires JavaScript to function anyway, so if JS is turned off, they can't really use the site anyway. Don't get me wrong, we're still looking for a preprocessing method, but so far performance hasn't really been an issue.

As always, use the right tool for the job.

That said, I caught your re-tweet on CSS4 selectors. I must admit I find it dismaying that CSS is pushing for more expressive selectors when what I and a lot of other Less & Sass developers really wanted was nested selectors, mixins, and variables/constants. At least there's discussion on variables...

[paulirish]

It's offtopic, but look at http://www.xanthir.com/blog/b49w0 for where the WebKit team wants to take CSS with regard to nesting, mixins, etc..

I agree that in a hosting environment that you don't have control over (and I suppose an unsophisticated build process), clientside is the only way. But that doesn't make it a recommended path.

IE7 has a massively slow javascript engine and has no localStorage. The styles are computed every pageload there. Also the caching doesn't help on first load, where a user is waiting to read your content. Anyone know what the benchmark timings are like in IE7?

Anyway, it's nice it works in the browser, but it shouldn't be a recommended solution for production and the site needs to ease up on the messaging around this.

[revolunet]

I agree it should be more clear on the website that client side processing should only be use for development and not production, when possible.

That said, its very handy to have client side processing for the dev :)

[cloudhead]

Noted. I would definitely not recommend it for IE7, or even 8. But if you're developing a javascript-heavy html5 app which targets modern browsers, there are advantages to having it run client-side. I know they were using it for custom themes on Bespin for example.

I'll put a warning up, targeting the older browsers.

Cheers

[paulirish]

Cool. Thx Alexis

[paulirish]

❤️

[lukeapage]

is this issue closed now paul?

[paulirish]

Nope. Right at the top of the site it still recommends the script tags
neccessary to run this clientside. That needs to be removed.

In the docs the clientside details should be moved below Serverside usage
and get a warning added that its for development iteration ONLY and should
not be pushed to production.

[designermonkey]

Therefore, with your argument, that whole section needs re-doing with regards to usage. The script tags are prominent, yes, but they relate to the download link, where you only get the js file, and not the server side files.

The links available make it very easy for people to start using LESS, which I think is more important than expecting users to have environments available with node on. Maybe the site needs altering, yes, but I really don't think that server side stuff should take precedence over quick, simple js implementation. That just makes it unobtainable for most users.

[sturobson]

I've just made a pull request for @cloudhead to change this on the github repo for lesscss.org @agatronic @paulirish

[paulirish]

linking up: less/old-lesscss.org#20

[tsi]

Would it be an option to develop using less.js, then export the compiled CSS, save it and push to production ?
Wouldn't that be even better then compiling server-side on production ?
I really don't see why your production server should pre-process your locally-developed CSS, ever.

[Soviut]

@tsi, typically that's what people do. They develop using the live javascript, then use a compiler to pre-process the less file when deploying to production. Sometimes they pre-process it locally and commit their generated CSS file, other times they let a post-pull script run that pre-processes the LESS files at that point.

It all depends on how automatic your deployment is, or perhaps, what you want to include in your repository.

[tsi]

They develop using the live javascript, then use a compiler to pre-process the less file

So your saying I must have a server-side compiler to save as CSS ? can't the result of the live javascript be saved to a CSS file ? that would make the whole process very simple and dev friendly, don't you think ?

[Soviut]

No, you can compile locally using the less compiler (a node.js module) from the command line, or SimpLESS (http://wearekiss.com/simpless), etc. Javascript in the browser cannot write to the local disk, so it can't create a local CSS file for you. However, the javascript LESS compiler does take advantage of Local Storage on browsers that support it by using it as a cache.

Also, most developers would consider an automated build a lot simpler in production than having to manually compile CSS files.

[lukeapage]

I switched the top of the site over to a node example. That way people have to click on usage and then read the warning about client side usage.

[paulirish]

ace. looks great. thanks!

[matthew-dean]

Thanks for bringing this up, @paulirish. Personally, even though I'm involved in building server-side tools for LESS, I wish the browser support was better. I know that what originally attracted me to LESS was the magic of inline compiling right on the page, and the fact that it employed local storage caching for quick retrieval of cached CSS. I think this has been an undervalued component of LESS, partly because browser support is so difficult and time-consuming. But the fact that it's been so prominent on LessCSS.org for so long speaks to how magical that is for devs. "You mean I can write in a different language and have it show up as CSS?"

My Christmas wish would be that part of the LESS team would be devoted to just the client-side browser side of things. It's just way too awesome to neglect.

But, as others have pointed out, server-side is still preferred as the best way to go about things, and its good to get the home page updated to highlight a server-side example.