Respectful opinion, but as an only part-front-end dev... > I don’t feel the “problems” CSS preprocessors intend to solve are serious enough to warrant the cost

Respectful opinion, but as an only part-front-end dev... > I don’t feel the “problems” CSS preprocessors intend to solve are serious enough to warrant the cost, i.e. to me the solution is worse than the problem. I don't think CSS preprocessors solve any problem per se, insomuch that C preprocessors solve any problems - they just help the code without introducing extra syntax to the core language. > I want absolute control of my CSS, which means I want to work hands on with it, and see exactly what will be sent to the browser (well, before it’s minified and gzipped, of course). If that means seeing the same declarations repeated in several rules, or having to see what vendor prefixes look like, so be it. To me, WET CSS is much more understandable and maintainable than DRY black box pseudo-CSS. I don't see how this argument is different from refusal to use any language other than C for complete control. While it does give you complete control, often times it may not even be worthwhile. In fact, SASS constructions are well-defined(enough) that most of time, you can derive exactly how the resultant CSS will look like; of course, some minute optimization may be required but the same argument can be made by pointing out that dlls exist. > I don’t want to learn and depend on a non-standard syntax to wrap my CSS in, making it require compilation before browsers can understand it. Neither do I want my colleagues to have to. Unless your team uses two different method of compilation on one environment(i.e., agreeing on which implementation to use), I doubt there'll be any problem with consistency. If you do use different compilations so that standardness matter, then you have a different problem. > I want my source CSS to be deployable at all times, albeit in un-minified, un-concatenated form. If my build process fails, for whatever reason (like an unpublished npm module), I can deploy the source CSS as an emergency solution. Performance may perhaps take a hit, but a slightly slower site is likely better than a site with broken or no CSS until the build process can be fixed. This is a non-sequitur on a hypothetical situation on artificial emergency. > I don’t want to have to wait for compilation before seeing the results of my CSS changes. Processing time may be anything from negligible to frustrating, obviously, but if it takes longer than the time it takes for me to switch from my code editor to my browser and reload the page (≈1s) it’s too slow. filesystem watch generally handles the auto-compilation, and am I the only one who edits css on-browser first before editing files on CSS sheet? If the only way to edit styles on web page is editing the source and reload, this method will definitely cause much more frustration on dynamically generated applications. I can sort of see where this person is coming from, but I would say the benefit outweighs the cost here. Again, personal preference, but I would rather have my team employ preprocessor just for variables and palette from designs.