TL;DR — preprocessors can be fantastic tools in the right hands. Tread carefully. In my experience, the longer you use them, the less useful they become. More than anything, it depends.
In case you still don’t “get it”, here’s an example of the syntax for one of the popular CSS processors, LESS. Here’s the code you punch in:
And here’s what would get spat back out the other side:
Pretty fantastic, right? You can see why people are getting so excited about preprocessors. They make a lot of hellish stuff a breeze, particularly when managing a large website.
I don’t like preprocessors. I’m a CSS masochist. <!– more –>
You’re insane, Dan.
So I’ve been told. People don’t seem to get it when I tell them that it feels to me like if you’re relying on tools like LESS or SASS, you’re going to cause yourself problems and enforce potentially bad habits. You don’t need tools - you just need to write better CSS. Well documented CSS with structure.
So what problems are you likely to encounter? Well, first there are the tools themselves. I’m going to be talking about LESS and SASS here, because they’re the most talked-about tools and they’re also the ones I’ve used myself.
In my experience with LESS, once you start nesting rules, it can cause a real specificity headache. Since it chains selectors depending on where you nest them, you’re likely to end up with over-specific selectors, decreasing the performance of your CSS, as well as the portability of your styles.
Another thing that boggles me is mixins. They’re a pretty smart idea, actually. You can declare a set of rules in a sort of component that can be reused in your CSS. Wow, that’s brilliant!
Wait. Don’t classes do that?
I know that’s a silly example - most people would use a class anyway, and mixins are better suited for allowing variables in declarations such as border-radius - but preprocessors could enforce the idea that this sort of authoring is acceptable.
That’s true. Variables were one of the more attractive features of preprocessors for me. But once again, logic and good documentation can triumph over preprocessors.
If you struggle to do a find and replace in your favorite code editor, you probably need a new code editor. One thing I’ll say in favor of preprocessors are the math functions. They’re pretty neat. Particularly when it comes to dealing with colors.
Your arguments are weak.
I know they are. I also know that I’ve probably been using these tools completely the wrong way. On top of that, I know I’ve not been working on a large-scale site, where these tools most likely come into their own a lot more.
But that’s beside the point. I raise these concerns because they’ve stuck out to me during my time with these tools. I fear that people starting to use CSS for the first time might be lead into terrible habits enforced by preprocessors. I know I would have been. It happened with jQuery.
So what about server-side preprocessing? Maybe, but this just feels like we’re clutching at straws. Why leave the server with work to do that can be easily done by the browser? I’m going off on a slight tangent here, so let’s bring this back home.
The bottom line is - as it is with most things - it depends. It depends on the size of the project, the number of people on the team, and a huge variety of other variables. All I know is that I don’t like them. But maybe I’m doing it wrong. I just feel like the long, hard, stupid way makes more sense to me.