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:
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.
Comments
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.
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.
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.
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/
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/
Yeah I would go with lesscss.org
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?
resharper has had a very negative impact on my development experience. Using VS without resharper drives me almost to insanity.
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
Alex, All of the stuff that I talked about are using the .NET dll, it is just different ways of invoking it.
Frank, But it doesn't impact anyone else who is using it.
Have you seen http://clientdependency.codeplex.com/ ?
Comment preview