Mis-leading "client-side" text about less-docs

[jonschlinkert]

yeah that's a much better description

[Soviut]

I agree. Though perhaps we can provide actual situations where both would be used. Nothing too verbose, just some clear delineation between the two in order to make the choice obvious. I would literally have two lists, side by side, titled "Should I compile?" and "Should I run live?" and outline reasons for each.

We've encountered enough people producing dynamic libraries/frameworks/sites that listing them will help both newcomers and people looking to do cutting edge dynamic stuff.

[jonschlinkert]

Great ideas, IMO you should just create exactly what you're saying right here and we'll build on it. The docs will be all in markdown so this kind of conversation will be a good start

[Soviut]

Okay, I'll start this off. Correct me if any of the points aren't true enough:

Should I compile?

• I'm in production and I don't want LESS taking extra time to compile my stylesheets (every millisecond counts)
• I want to see the generated CSS so I can optimize my LESS
• I want to further minify my CSS after it's compiled
• I want to post-process or trigger other build steps*** needs work

Should I run live?

• I'm in development and don't want to run extra tools while I test
• I'm working in a remote sandbox that won't let me compile but I don't want to keep uploading compiled CSS files while I test
• I need to pack everything into one HTML file for templating reasons
• I'm creating a dynamic templating system that needs to update on the fly
• I'm comfortable with only supporting the most recent browser versions (less.js does not attempt to remain compatible with older browsers)

[andrewwakeling]

I'm seeing the "intended usage" quoted in response to a few issues raised. (e.g. less/less.js#1654).

From what I'm observing it should clearly say:
"If you are using LESS in production you should NOT use 'less.js' and you should be compiling your stylesheets."

...and maybe even go as far to say, "If you decide to use 'less.js' in production, you do so at your own risk."

I am a bit saddened by the lack of enthusiasm in encouraging the "sensible" usage of less.js in production because I see this as being LESS's strongest and most unique feature in comparison to other stylesheet languages.

[Soviut]

That's why I think my suggested "when should I compile, when should I run live/less.js?" side-by-side comparison is crucial. It allows people to understand the pros and cons of both before they choose.

We've seen a lot of recent issues from people who are basically just suffering from a bad workflow complaining about less.js

[jonschlinkert]

We've seen a lot of recent issues from people who are basically just suffering from a bad workflow complaining about less.js

Indeed. I have to be blunt thought, from the time I first heard about less.js (2 years ago), I remember reading time and time and time again not to compile in the browser unless you absolutely needed to. This has never been hidden information. At this point we're splitting hairs on how to say the same thing differently - but no matter how we say it, people who don't RTFM will come here and complain about the same point over again.

[jonschlinkert]

.. and I'm not trying to be harsh, it just seems like the reality of it

[Soviut]

I know that when I got into LESS, the first instructions on the site that I saw were "here's how easy it is to add in the browser". This was important as it gave me a low barrier to entry, but there was no clear instructions on how to deal with production. As a result, one site I built several years ago still has less.js being used in production.

Now that so many handy desktop compilers and workflow tools like Grunt exist, illustrating those early on the website, right next to less.js instructions would go a long way to preventing newcomers from travelling too far down the wrong path.

Hell, let's make a featurette video.

[jonschlinkert]

illustrating those early on the website, right next to less.js instructions would go a long way to preventing newcomers from travelling too far down the wrong path.

Agreed. Let's do that. The featurette video is a good idea too. I've wanted to get code mirror hooked up so that users can play with the code examples too.