On writing real CSS (again)

Avatar of Chris Coyier
Chris Coyier on

DigitalOcean provides cloud products for every stage of your journey. Get started with $200 in free credit!

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

PostCSS and cssnext are certainly interesting projects to keep an eye on. It’s pretty easy to devil’s advocate on all the major points here though…

  • 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.

Direct Link →