Cole Peters on the current pre-processor landscape and ditching Sass for PostCSS:
… here’s what we gain by using PostCSS and cssnext, as compared to typical pre-processors:
- extremely fast compilation times (in my example case, ~800% faster)
- source code written in CSS, as defined by current and upcoming specs, which means:
- no vendor-specific syntax (unless we write our own — be careful!), and thus:
- source code that is immediately comprehensible to anyone with a half-decent understanding of CSS, and:
- source code that is future-proof, portable, and easier to diagnose and debug
- How fast does compiliation need to be? I don’t even use libsass on most projects and speed never bothers me, and once I switch, that seems like that will be as fast as a build step would ever need to be.
- We know that specs change. It happens all the time. Seems weird to base a syntax on a non-final spec. What happens when the spec changes? Do you change the language and let existing code break? How is that future-proof? Or support all past formats? Meaning the language isn’t really based on future CSS, it’s based on any experimental idea that was considered?
- The opt-in add-on system encourages everyone’s setup to be a little different. Doesn’t that make it actually less portable? And harder to have community around?
- Why is it more comprehensible? I’m not sure it’s true that just because code might someday be a native part of the language it’s automatically more understandable. From what I’ve heard from people, things like variables are a harder to wrap your head around than a standard Sass variable. Not to mention it’s a bit confusing that it’s impossible to polyfill the exact native behavior in a preprocessing step.
All interesting things to consider. Personally I like the idea of a preprocessor being more like a polyfill when possible, but I also think abstraction should be embraced not feared.