Ayende @ Rahien

It's a girl

Fix the code, not the tooling

This is a story from the time (all those week or two ago) when we were building RaccoonBlog. The issue of managing CSS came up. We use the same code base for multiple sites, and mostly just switch around the CSS values for colors, etc.

It looks something like this:

image

We are using the less syntax to generate a more reasonable development experience with CSS. We started with the Chirpy extension, which provides build time CSS generation from less files inside Visual Studio.

Well, I say started because when I heard that we were using an extension I sort of freaked out a bit. I don’t like extensions, I especially don’t like extensions that I have to install now on every machine that I use to work on RaccoonBlog.  The answer to that was that it takes 2 minutes or less, and is completely managed within the VS AddIn UI, so it is really painless.

More than that, I was upset that it ruined my F5 scenario. That is, I could no longer make a change to the CSS file, hit F5 in the browser and see the changes. The answer to that is that I could still hit F5, I would just have to do that inside of Visual Studio, which is where I usually edit CSS anyway.

I didn’t like the answers very much, and we went with a code base solution that preserved all of the usual niceties of plain old CSS files (more on that in my next post).

The problem with tooling over code is that you need to have the tooling with you. And that is often an unacceptable burden. Consider the case of me wanting to make a modification on production to the way the site looks. Leave aside for a bit the concept of making modifications on productions, taking away the ability to do so is a Bad Thing, because if you need to do so, you need to do so Very Much.

Tooling are there to support and help you, but if tooling impact the way you work, it has better not have any negative implications. For example, if one member of the team is using the NHibernate Profiler, no one else on the team is impacted, they can go on and develop the application without any issue. But when using a tool like Chirpy, if you don’t have Chirpy installed, you can’t really work with the application CSS, and that isn’t something that I was willing to tolerate. Other options were raised as well, “we can do this in the build, you don’t need to do this via Chirpy”, but that just raised the same problem of breaking the Modify-CSS-Hit-F5-In-Browser cycle of work.

The code to solve this problem was short, to the point and really interesting, and it preserved all the usual CSS properties without creating dependencies on tools which might not be there when we need them.

Tags:

Posted By: Ayende Rahien

Published at

Originally posted at

Comments

Simon Bartlett
06/06/2011 10:41 AM by
Simon Bartlett

Ayende, I use less css on one of my projects. I solved this problem by using the compiler executable from the dotless project, and adding a build step to my .csproj file. I have the compiler checked in to source control. Any developer who works on my project can check the code out and just hit F5 with no extensions/plugins required.

Simon Bartlett
06/06/2011 10:47 AM by
Simon Bartlett

dotless also has a HttpModule so it can compile and cache less files at runtime, although I am not sure if it can detect live file changes.

Robert Byrne
06/06/2011 11:04 AM by
Robert Byrne

Second the HttpModule approach, it gives you exactly the same editing experience as plain CSS with all the benefits of less css. I mainly stayed away from Chirpy because I didn't want all the bloat of designer generated files everywhere (even if you can join them together for inclusion).

I'm 50/50 when it comes to designer tools, anything that could be edited usually requires a compilation/minification step of some sort before going to production (including JS and CSS on most apps). If I need to be monkey patching live CSS, the generated output from CSS less is very easy to follow.

Sam
06/06/2011 01:00 PM by
Sam

We use the dotless parser directly from code to generate custom CSS for a white-labelled application (and MVC output caching does the rest). No tooling required.

http://samritchie.net/2011/05/23/dotlessresult-mvc-actionresult-for-dotless/

Adam
06/06/2011 01:19 PM by
Adam

Less.js is also another option which is pretty good. It compiles less to css and loads it on the fly when the page loads.

http://lesscss.org/

zvolkov
06/06/2011 01:51 PM by
zvolkov

Yeah I would go with lesscss.org

Alex K
06/06/2011 04:36 PM by
Alex K

So why were you using the weird extensions and .js and not the .Net dll (http://www.dotlesscss.org/) and have everything just the way you wanted?

Frank Quednau
06/06/2011 05:38 PM by
Frank Quednau

resharper has had a very negative impact on my development experience. Using VS without resharper drives me almost to insanity.

Daniel Hölbling
06/06/2011 08:06 PM by
Daniel Hölbling

I don't know if you know this, but Chirpy uses the dotlesscss framework underneath and we do provide a HttpHandler that you can register in your web.config that can be shared through Git and that works quite well during development. And when you go to production you can use the accompanying dotless compiler to turn the .less into regular CSS avoiding any incurring costs.

Or, you could use the dotless.compiler all the time during development as it includes a --watch option that will re-generate all your .css files whenever your .less files change.

more info on dotlesscss: http://www.dotlescss.org

greetings Daniel

Ayende Rahien
06/07/2011 07:06 AM by
Ayende Rahien

Alex, All of the stuff that I talked about are using the .NET dll, it is just different ways of invoking it.

Ayende Rahien
06/07/2011 07:06 AM by
Ayende Rahien

Frank, But it doesn't impact anyone else who is using it.

Bolo
06/07/2011 11:12 AM by
Bolo

Have you seen http://clientdependency.codeplex.com/ ?

Comments have been closed on this topic.