However, the variables, mixins, extends, nesting etc., in preprocessors forces us to define our approach to write CSS in a programmatic manner rather than aesthetic one. Hence, it is easier to get carried away and lose the bigger picture, isn’t it?
Pundits will quickly discard this point as almost every CSS preprocessing tool on this earth is capable of minifying the output CSS. However, the final file size has more to do with the code written inside the file than just gzip and minification.
Studies have proved that preprocessors have the tendency of generating redundant snippets of code, when the actual css could have been much smaller.
Lea Verou explains this phenomenon with examples in her opinionated article on CSS preprocessors.
I write my CSS in either Notepad or Vim. The editor and the browser are the only 2 pieces of software that I use for front-end development.
I don’t want to add additional tools or libraries to my existing workflow. I prefer to keep my workflow light and portable that allows me to work on my code literally from anywhere on any operating system. But preprocessors flirt with this principle since they cannot work without additional toolset like - Ruby (for Sass on Windows) and Node PM (for LESS).
For a team of CSS developers, do you really expect each one of them to know Sass/LESS? If no, then what happens if another developer wants to edit the CSS file but doesn’t know Sass?
Debugging is even harder; when you know that the developer tool of the browser shows you the code and the line number of the css file. Do you want to manually trace the piece of code in your Sass file?
I do understand the advantages and the benefits that these preprocessors bring to the plate, but with an additional cost. There are counter-arguments probably to every point that I have made in this article. But that still wouldn’t change my opinion and the way I feel about CSS Preprocessors.
I don’t hate them but I don’t like them either!