In the last few days I’ve been investigating CSS post‐processing, the idea behind which – writing stylesheets using partially implemented or emerging standards, which are then transpiled to make files which work in current browsers — is more pleasing to me than the abstractions of pre‐processors like Sass. I’ve been experimenting with PostCSS (or rather, cssnext, which is to PostCSS as (broadly) Bourbon is to Sass); however, there are a couple of problems with post‐processing, at least in the way that PostCSS approaches it, which makes me question its utitility.
NB I must state clearly that these observations are based on a very shallow understanding from my initial investigations of how PostCSS works, and perhaps they would be clarified and resolved if I tried to use it on a full project. Update: See also the comments below this article, which clear up some of my misconceptions.
The first is that post‐processing uses syntax from proposed standards which have yet to be ratified. For example, the variables syntax is based on Custom Properties which, athough implemented in Firefox, are yet to have any firm commitment from other browser vendors; the syntax could still be changed, or indeed dropped entirely. That would mean PostCSS would have to either retain an outdated syntax for backwards compatibility, or change it completely to match future decisions, making maintainability of old projects harder for developers.
The second problem is that the features of Sass which are most useful (and widely used) are those which greatly extend the core CSS syntax – notably, nesting and mixins. While there are PostCSS plugins that add extensions to match pre‐processing features, using them means that your source stylesheet is no longer ‘proper’ CSS — which is the main attraction of a post‐processor to me. If your source stylesheet is largely invalid, you might as well use a pre‐processor.
Perhaps, as Lyza Danger Gardner concluded, using post‐processors means giving up certain features:
Taking a path paved with lean, modular post‐processing plugins involves sacrifices. No more nesting. Instead of an endless horizon of mixin possibilities, you may be bound to CSS spec realities, like
calcor CSS variables.
I still like the idea of post‐processing, but perhaps I need a longer period of acclimatisation before it fully makes sense to me.