Awesome that you guys our now supporting/focussing/using .less but why this way?
Why waste precious development time to build a compiler if there's already the official less.js we've got dotless which is a dotnet port and instantly available NuGet package and VisualStudio now officially supporting .less files ?
As of VisualStudio 2013, .less is an equal senior citizen to .css and for those developers still on VisualStudio 2012 or VisualStudio 2010 there's the WebEssentials extension.
Why have me worried about compiler compatibility and less features working?
No offense but keeping jQuery smooth is already providing troublesome enough, it's not your core business and it shouldn't be.
LESS is prodominantly a development 'language', and for those who don't mind there are easy ways to compile .less on a production server in runtime.
Most of us, don't want that. Don't want the server overhead, not the chance of things breaking nor the chance of a compiler running out of memory and breaking an entire site.
Perhaps I'm overly worried but I'm sure 2-3 versions down we're going to see you guys dynamically adding in .less files in our theme-loading when you're going to need additional styles for say inline-editing etc and stuff like that is bound to screw up because of re-used variables or double named mixins etc.
I know someone must have said internally, lets become be more flexible and better manage our stylesheets and someone suggested .less for it but please, cancel the custom compiler part.
There are better and more useful ways of getting your dll based styles loaded optimally - adding a layer of potential failure to the production environment isn't the best way to do this.
I'm sure the first response is going to be "hey you don't have to use it if you don't want to, .css is still going to be supported" but knowing Telerik, if you continue to develop the compiler, you guys are going to use it.
Scenario's like Steve's wishlisht can already be done using existing components/tools and there's no real client nor a development benefit from compiling .less on the server nor having to test a production environment for dynamically generated css.
If you guys want to score points with devs and client by getting the number of requests down, why not look into bundling and minification? Build a better CSS and JS widget that grabs and combines all of them on a page.
Or enhance the page editor with RequireJS, so that for each widget we could say require this-and-that file and the system would async load this for us once page rendering is complete. RequireJS already has a plugin system for css files so with a single require statement like this:
I could tell the system, make sure jQuery is loaded, load this additional .JS file, this css file and a certain image and when done execute this JS. And all that would be done async - after the page has been rendered.
Combine that with proper bundling/minification support as mentioned before and with a bit of cramming and luck for each individual page you'd get only one additional css request and one additional JS request on a page load and async load the rest.
That's way more useful than a build in compiler, mimicking widely available tools and simultaneously adding another layer of possible failure.
To be clear, YES! on .LESS but please don't continue development of the compiler....