The drawbacks of post‐processing

Warning This article was written over six months ago, and may contain outdated information.

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.

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 calc or 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.

Related

5 comments on “The drawbacks of post‐processing”

Hey,
The main problem here is that postprocessors are misunderstood. For me, cssnext is not a postprocessor, it’s basically a preprocessor with future (hypothetical) syntax.

At the beginning, PostCSS was only for postprocess CSS (as it’s its name), but then it allows to create our own preprocessor, with any syntax we want.

In my opinion, post­proces­sors have to be implicit to silently improve CSS (prefixes, fall­backs, etc.) and pre­proces­sors have to be explicit (use its own lan­guage) to gen­er­ate CSS.

For example, in cssnext, you can use CSS custom properties to emulate variables (as you write in your article), but you’re limited to define them in :root. As @chriseppstein wrote on Twitter a while ago: “Relying on developer self‐restraint is a poor software design methodology”. If a preprocessor restrained variables declaration, people wouldn’t have use it.

Pre­proces­sors and postprocessors work well together, and this is the best workflow imo. That’s why I’ve cre­ated my own tool: Pleeease. :)

The main idea behind PostCSS (and post‐processing in general) is not to use syntax from proposed standards (this is one of many possibilities), but to use multiple easy‐to‐write JS plugins instead of huge monolithic pre‐processors. It makes possible to reach your goals instead of learning another poorly‐designed CSS‐like language. If your goal is to keep your styles compatible with CSS — use proposed syntax, if not — use anything you want.

post‐processing uses syntax from proposed standards which have yet to be ratified … 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.

This isn’t true. Node modules, including PostCSS modules, take advantage of SemVer. When the breaking change ships, you either upgrade or you don’t. No harm done.

What you’ve described is actually a strength of more modular systems (e.g. PostCSS or eslint) because with a larger, comprehensive library like Sass or jshint, you either upgrade the whole thing or you don’t. With PostCSS everything is modular so you can choose to upgrade each tiny piece as it changes, and do your refactoring at your own pace (or not at all).