Just finished reading What Will Save Us from the Dark Side of CSS Pre-Processors? on A List Apart. I found the title and initial tone of the post confounding. And well, I probably read the post in the first instance, to shout down the wildly unfair negative connotations attached to preprocessors.
The thing is, I love preprocessors. I love them so much that I'm currently brewing a series of posts extolling the virtues of preprocessors. Then I'm faced by a post by A List Apart (a site I have a lot of respect for), apparently prophesying the demise of these little wonders. I couldn't let the post go, what if they were right?
After all, its up to all of us to constantly question everything we believe to be true. Right? Right.
The arguments set forth for the problems with preprocessors are:
- Unmindful use of preprocessors creates bloated output.
- By adding a layer of abstraction on the base syntax, you're essentially locking yourself into it's Domain-Specific Language (DSL).
Blaming the use of a preprocessor on the coder's own bad habits, is like blaming traffic cameras for speeding. To get the best out of a tool, you must use it correctly. I'm no shining example of this! I frequently try to nail pictures to the wall with a screwdriver; I'm forever using an unnecessary amount of nesting in my Sass.
You can't deny 'lock-in' effort of adding a preprocessor to a project. In much the same way, you could argue that choosing to write an application in a language like Ruby), locks the future development to the that language over say the base languages that Ruby is built on, like C or Java.
Well, that's not quite right, you could write a native extension for Ruby in C, if you wanted. Actually, this is why I use the SCSS syntax of Sass over SASS, and why I favour 6to5 over CoffeeScript. In both examples you can make use of all the wonderful syntactic sugar that the preprocessors provide, or ignore all of it and write in the base syntax. Let us not forget that we're never ever actually locked in by a good preprocessor, as its sole purpose is to generate the base syntax, so you can opt out at any time. "Hey man, I don't need your syntactic goodness anymore, I'm going to carry on with the base file".
A couple of issues are raised by my last paragraph:
Why would you ever just use the base syntax, if you'd gone to the trouble of adding a preprocessor in the first place? I'm completely non-dismissive of Lyza's arguments about the 'lock-in' effect, or as I've always thought of 'barrier to entry' or 'learning curve'. I work in a very talented dev team. We each come from different technological backgrounds and have our own preferences for tooling & technology. If I'm going to add a dependancy to the project, it better not be at the expense of a co-worker's ability to jump in.
Its at the point where Lyza starts talking about post-processors, that my angst starts to wain. I'd never heard of PostCSS or Myth and I'm pretty excited about both. I use Compass a lot; the moment that hooked me was realising that I didn't have to hack around with nonsense bits of CSS, to add cross browser support for
_Note: I've used some of those double quotes divisively, I wonder if you noticed. It seems to me that the use of "pre" and "post" refers to the point at which the code is compliant to a standard. So, 6to5 is actually a post-processor. I went to the site for clarification. 6to5 actually refers to itself as a transpiler, which is a marvellous way of avoiding a distinction that I care very little about._
In summation, Lyza's point (I believe) is that transpilers aren't there to cover up poor code, that diversity in one's approach (especially within a team) is good. If I'm right, then I agree with her wholeheartedly in both regards. I don't agree with the negative connotations of so-called preprocessors & post-proprocessors to get to these points though.