Upgrade LESS to 1.5.X

[chubbard]

Currently this plugin ships with 1.3.3, but less is on version 1.5. It'd be great if this was updated to ship with the latest version of LESS compiler.

[paulfairless]

The plugin ships with the latest version of the Java Less Compiler (1.3.3). I will release a new version once this is updated.

[chubbard]

That doesn't look so good being that nothing has happened in that project in 4 months.

[cweekly]

Opinion [which may fairly be deleted if it's not appropriate here]:
LESS was originally designed to be compiled to CSS in the browser. That's kind of insane from a webperf POV. So moving it to the server made sense, hence lessc referenced from Grails (or any other framework) is a step in the right direction. However, this still adds unnecessary overhead. Unless you have some unusual setup where you need to dynamically recompile LESS to CSS at runtime, it doesn't make sense to ask your app to do this step. The standard use case for LESS is rather as part of the web developer's workflow, as the app's styles are being edited. What gets deployed can (and IMHO should) simply be the compiled CSS. So, my recommended approach is to take the lessc step out of your app altogether, and rely instead on an offline / dev tooling process. Options abound, including tools like LiveReload as well as any number of node-based solutions, including many npm modules and grunt tasks.

I actually wrote a standalone npm module last year for this purpose, but I'm not linking to it here b/c I don't want my point to be lost with a mistaken impression that I'm trying to drive up the number of users of my tool. (On the contrary I'm thinking of abandoning that tool in favor of rolling lessc into my nascent grunt setup.)

Anyway YMMV but IMHO, any opportunity to reduce reliance on plugins (which always seem to accrue further daisy-chained external dependencies) is usually worth considering. In this case, I think there's a compelling case to be made to obviate the need for the plugin altogether.

And I write this with all due respect to the Grails plugin authors who thanklessly share their work. I hope no offense is taken, bc none was intended!

/$.02
cweekly

[paulfairless]

I agree to some point, stepping outside of the framework can introduce more opportunities for build time errors, as manual build steps can be easily forgotten. What is clear is that the java tooling is not keeping pace with the libraries themselves.

Grails 3 is moving away from it's custom build steps and will be using Gradle, this will in open significant new options. I think it will become the norm to use Grunt for all these types of build tasks (Grunt and Gradle work ok together).

Until then I will obviously continue to support the plugin given the constraints of the eco system it belongs too.

No offence, but I don't agree with @cweekly's view that the compilation of LESS should be a manual step rather than part of the build. It's only a matter of time before I'd forget to do this, and end up deploying LESS files rather than CSS. The extra overhead introduced by compiling the LESS files to CSS is a price I'm happy to pay the eliminate the aforementioned risk

[cweekly]

Donal, you misunderstand me completely.
It should be automated!
But using node+grunt, offline, at build time -- once -- not on the server
w each request!

On Tuesday, January 28, 2014, Donal notifications@github.com wrote:

No offence, but I don't agree with @cweekly https://github.com/cweekly's
view that the compilation of LESS should be a manual step rather than part
of the build. It's only a matter of time before I'd forget to do this, and
end up deploying LESS files rather than CSS. The extra overhead introduced
by compiling the LESS files to CSS is a price I'm happy to pay the
eliminate the aforementioned risk

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/51#issuecomment-33546515
.

http://www.chrisweekly.org

@cweekly AFAIK, the compilation of LESS resources to CSS resources only happens at built time unless you're in development mode. In the latter case it only happens with each request if a LESS resource has been changed. It's not obvious to me what the problem with this approach is

[cweekly]

@donal ah, I think you're right about dev mode vs prod mode. Personally I still don't like it (the fewer diffs between dev mode and prod the better), and the fact remains that it doesn't work smoothly for many users. I like having control, and using grunt puts me in complete control. Relying on a 3rd party plugin -- which in turn depends on other 3rd-party plugins -- leaves me feeling helpless if it stops working, as has happened a number of times per my experience as well as, well, the issue we're commenting on here. For something as simple -- and as specific to webdev workflow -- as lessc, relying on a plugin in the framework seems like the wrong approach. To me. Respectfully. YMMV.

I don't know anything about Grunt, so don't understand what you're proposing as an alternative. Personally, I like the fact that in dev mode the LESS files are automatically recompiled when they change. If I had to remember to do something to make this happen, I would find it less convenient than the current solution.

I appreciate that in general dev should be as close to prod as possible, but in this case the behaviour desired (by me, at least) in each environment is fundamentally different: we want to recompile changed LESS resources on each request in dev only.

[cweekly]

Recompiling less to css on each request doesn't ever make the most sense though, even in dev mode. Recompiling less to css automatically when the less changes, and having the server only aware of the compiled css, is simpler and better, imho.

With grunt, I'm running a watch task that automatically does the lessc when less files change. It's more configurable than any of the grails plugins (e.g. distinguish between less files designed for import only, vs less files that are meant to become .css files referenced in the app). Grunt also provides a livereload server so the browser refreshes the stylesheet (and your scripts) (without a whole page refresh) as you code your changes. Its like working in Chrome DevTools, except you get to use your favorite IDE/Editor. Try it and you'll never go back. If you want help getting started let me know; I'm hoping to write a blog post about how to do this properly, but happy to help you in the meantime if you're interested.

FYI Grunt also provides things like minification, concatenation, linting, test running... all the good FE dev workflow stuff in one place. It's indispensable. :)

Thanks for the info about Grunt and the offer of help, I'll check it out

Recompiling less to css automatically when the less changes, and having the server only aware of the compiled css, is simpler and better, imho.

Isn't this what the LESS plugin already does (I'm not sure)? I would be very surprised if the LESS plugin always recompiles the LESS files on every request (even if nothing has changed).

[cweekly]

I might be out of date there (haven't used grails plugins for lessc in over a year). But in any case, the server footprint is bigger if it needs to know how to do lessc, and a grunt-based workflow is more dev friendly given all the other things you can do in grunt. Anyway if you're interested, http://gruntjs.com/getting-started is the place to start. Cheers!

Thanks for the Grunt link, I'll check it out

the server footprint is bigger if it needs to know how to do lessc

FYI, in production mode the only time the less plugin is only used at build-time. The plugin isn't included in the deployed .war file, so has zero impact on runtime performance.

[cweekly]

Ok cool, thanks for clarifying. :)

[paulcitarella]

It looks like the Java Less Compiler has been abandoned. Any chance that you can switch back to the Less CSS Engine? It seems to be better maintained. This would at least support Less 1.4.2 in it's current version and would allow users of this plugin to compile Bootstrap 3. Otherwise, anyone looking to use the latest Bootstrap is on their own.