Pelle Wessman

Some good thoughts on PostCSS from: https://css-tricks.com/the-trouble-with-preprocessing-based-on-future-specs/

If you’re a user of a future-syntax preprocessor, you have to accept that you’ll face breaking changes that come along somewhat randomly.

​This is very true. When using eg. Sass you're working against a finalized syntax that's likely to supported for years to come. When working on future syntax that might still be early drafts, then you should expect it to change as no promise that it shouldn't has been made and it's important that the specifications of new features can be iterated on so that once they are final they are in the very best shape they can be as then we're stuck with them forever.

Say you want to start actually shipping some future-syntax code because some browsers are starting to support it. But your preprocessor is still processing it, and you can’t remove the preprocessor because a lot of browsers aren’t supporting it yet.

​Preprocessing future-syntax stops you from using that syntax natively as a way to progressively enhance your site. As pointed out elsewhere in this article not all features can be fully preprocessed into existing CSS and by not being able to make use of the full features in the browsers that support them you're actually left with a less powerful and less forward looking stylesheet – compared to if you would instead adopt a progressive enhancement strategy.

Preprocessor variables and native variables could co-exist and be useful in their own ways.

​Exactly. Use of new features through progressive enhancement.

If native CSS could do everything ever dreamed up in a preprocessor, it would be slow, complicated, and likely wouldn’t have seen the success that CSS has had as a language.

​A beauty of eg. Sass is the pre-part of preprocessing. All execution and complexity are made before it reaches the browser and while we may complain about how that slows us down as front-end developers as we now has a self-imposed compilation step it makes it possible for us to do complex and costly things without the underlying standard having to support that itself. We can get the relative simplicity of CSS while still having the powerful features of something like Sass. That's not a bug, it's a feature.

PostCSS is a large plugin ecosystem and you use it by piecemealing together plugins you’re interested in using. That means any given project is using a different configuration of plugins. Any given chunk of code may not work in a different project using different plugins.

​The Unix philosophy is great. Have small modules that focus on just one thing and only on doing that one thing very well. But ecosystems are also good and in the case of preprocessors I feel that the ecosystem that eg. Sass have created, because everyone knows what features are available, has been great – especially since libsass pushed many to stop relying on Compass, something that when it was popular split the community in two and made some code hard to reuse.

Sass has also been relatively stable over the years. There has been some rough update paths, but generally you can still use the same code today that you could use years ago with little or no changes and for the few breaking changes that has happened, there's clear and simple documentation of those in the Sass documents.