I had a short twitter conversation with Aaron Jensen on the decisions we made developing .Less. As I’ve blogged about before, for me personally it was more of a learning project than something with a set goal, at first. That aside, I had one thing in mind: being able to use less during development, without having to worry about it, add a handler and go!
Less.Net, v0.1
My first solution was to simply install ruby and wrap the whole system call in a HttpHandler. Very clunky, but it worked! I blogged about this a while ago: Using LessCSS in an ASP.NET site.
I got it working, tried to implement it in my web project, and ran into another problem: It’s SLOW. Could be solved with caching, but in development I generally dislike that. It presents another point of failure which can take quite some time to figure out.
Another point was the fact that ruby should be installed. If you’re familiar with the .NET ecosystem you’ll know that a lot of people just want to deploy a single DLL and be done with it. Installing ruby, getting it to install a gem and then using that in your build process is quite a bit of work you want to avoid, if at all possible. That’s two problems I wanted to solve.
Being influenced a bit by the things I saw coming by on twitter (Linq to NHibernate to be exact) I looked into ANTLR for the parsing, which was simply an interesting technique to learn. I got a working prototype for a simple less file, published it, and got in touch with Daniel and Chris, with which we formed the current .Less project. Before joining up, Daniel gave IronRuby a shot for implementing the ruby gem in .NET, but it turned out to be too painful to deploy and too slow.
Perhaps with the next version of the CLR IronRuby will be a good option for Less, but honestly, I don’t expect that to be mainstream for at least another year.
Less.Net and nLess become .Less
After a few talks via skype, we decided to work on Chris’ codebase, called nLess at that moment. The reason why is that the grammar style he used is very similar to the ruby treetop grammar, which makes porting new language features quite painless. Also, I ran into a few problems with my grammar which would require quite a bit of rewriting of the grammar.
We’re not aiming for creating our own dialect, we want to adhere their standard as much as possible. The general idea is to introduce the less syntax in the .NET world, in such a way that it’s recognizable for the average .NET developer. That’s why having a grammar which is easily ported from one to the other is of great value to the project.
The future
While we do want to adhere to the ‘official’ syntax, we’re not bound to the functionality the ruby gem offers. We’ve got a few cool ideas we can do, but not before we’ve got a more edge cases of the current implementation covered. We’re also looking into creating a Visual Studio plugin, to, again, reduce the friction of using less in your ASP.NET solutions.
Another thing that’s on our agendas is to create more viable specs to test. We’re currently using the somewhat outdated ruby specs, which are generally very big umbrella specs. They also don’t exactly do what you’d expect. Hopefully we can create a common set of specs both the ruby gem as our .NET DLL, as the PHP version that’s around there can use. That way it won’t matter which environment you use, your less files will always work.
Well, that’s the story about .Less and how it came to be. If you’re interested in the project, I invite you to go to http://www.dotlesscss.com/ and try it out. We’re usually quite fast on the response to our google group, so if you want to ask anything, feel free to do so.