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 inves­ti­gat­ing CSS post-pro­cess­ing, the idea behind which – writ­ing stylesheets using par­tial­ly imple­ment­ed or emerg­ing stan­dards, which are then tran­spiled to make files which work in cur­rent browsers — is more pleas­ing to me than the abstrac­tions of pre-proces­sors like Sass. I’ve been exper­i­ment­ing with PostC­SS (or rather, css­next, which is to PostC­SS as (broad­ly) Bour­bon is to Sass); how­ev­er, there are a cou­ple of prob­lems with post-pro­cess­ing, at least in the way that PostC­SS approach­es it, which makes me ques­tion its utitility.

NB I must state clear­ly that these obser­va­tions are based on a very shal­low under­stand­ing from my ini­tial inves­ti­ga­tions of how PostC­SS works, and per­haps they would be clar­i­fied and resolved if I tried to use it on a full project. Update: See also the com­ments below this arti­cle, which clear up some of my misconceptions.

The first is that post-pro­cess­ing uses syn­tax from pro­posed stan­dards which have yet to be rat­i­fied. For exam­ple, the vari­ables syn­tax is based on Cus­tom Prop­er­ties which, athough imple­ment­ed in Fire­fox, are yet to have any firm com­mit­ment from oth­er brows­er ven­dors; the syn­tax could still be changed, or indeed dropped entire­ly. That would mean PostC­SS would have to either retain an out­dat­ed syn­tax for back­wards com­pat­i­bil­i­ty, or change it com­plete­ly to match future deci­sions, mak­ing main­tain­abil­i­ty of old projects hard­er for developers.

The sec­ond prob­lem is that the fea­tures of Sass which are most use­ful (and wide­ly used) are those which great­ly extend the core CSS syn­tax – notably, nest­ing and mix­ins. While there are PostC­SS plu­g­ins that add exten­sions to match pre-pro­cess­ing fea­tures, using them means that your source stylesheet is no longer ‘prop­er’ CSS — which is the main attrac­tion of a post-proces­sor to me. If your source stylesheet is large­ly invalid, you might as well use a pre-processor.

Per­haps, as Lyza Dan­ger Gard­ner con­clud­ed, using post-proces­sors means giv­ing up cer­tain features:

Tak­ing a path paved with lean, mod­u­lar post-pro­cess­ing plu­g­ins involves sac­ri­fices. No more nest­ing. Instead of an end­less hori­zon of mix­in pos­si­bil­i­ties, you may be bound to CSS spec real­i­ties, like calc or CSS variables.

I still like the idea of post-pro­cess­ing, but per­haps I need a longer peri­od of accli­ma­ti­sa­tion before it ful­ly makes sense to me.

 

5 comments on
“The drawbacks of post-processing”

  1. Hey,
    The main prob­lem here is that post­proces­sors are mis­un­der­stood. For me, css­next is not a post­proces­sor, it’s basi­cal­ly a pre­proces­sor with future (hypo­thet­i­cal) syntax.

    At the begin­ning, PostC­SS was only for post­process CSS (as it’s its name), but then it allows to cre­ate our own pre­proces­sor, with any syn­tax we want.

    In my opin­ion, post­proces­sors have to be implic­it to silent­ly improve CSS (pre­fix­es, fall­backs, etc.) and pre­proces­sors have to be explic­it (use its own lan­guage) to gen­er­ate CSS.

    For exam­ple, in css­next, you can use CSS cus­tom prop­er­ties to emu­late vari­ables (as you write in your arti­cle), but you’re lim­it­ed to define them in :root. As @chriseppstein wrote on Twit­ter a while ago: “Rely­ing on devel­op­er self-restraint is a poor soft­ware design method­ol­o­gy”. If a pre­proces­sor restrained vari­ables dec­la­ra­tion, peo­ple would­n’t have use it.

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

    Vincent De Oliveira [May 28th, 2015, 17:33]

  2. The main idea behind PostC­SS (and post-pro­cess­ing in gen­er­al) is not to use syn­tax from pro­posed stan­dards (this is one of many pos­si­bil­i­ties), but to use mul­ti­ple easy-to-write JS plu­g­ins instead of huge mono­lith­ic pre-proces­sors. It makes pos­si­ble to reach your goals instead of learn­ing anoth­er poor­ly-designed CSS-like lan­guage. If your goal is to keep your styles com­pat­i­ble with CSS — use pro­posed syn­tax, if not — use any­thing you want.

    Andrey Sitnik’s PostC­SS pre­sen­ta­tion slides http://ai.github.io/about-postcss/en/

  3. post-pro­cess­ing uses syn­tax from pro­posed stan­dards which have yet to be rat­i­fied … That would mean PostC­SS would have to either retain an out­dat­ed syn­tax for back­wards com­pat­i­bil­i­ty, or change it com­plete­ly to match future deci­sions, mak­ing main­tain­abil­i­ty of old projects hard­er for developers.

    This isn’t true. Node mod­ules, includ­ing PostC­SS mod­ules, take advan­tage of SemVer. When the break­ing change ships, you either upgrade or you don’t. No harm done.

    What you’ve described is actu­al­ly a strength of more mod­u­lar sys­tems (e.g. PostC­SS or eslint) because with a larg­er, com­pre­hen­sive library like Sass or jshint, you either upgrade the whole thing or you don’t. With PostC­SS every­thing is mod­u­lar so you can choose to upgrade each tiny piece as it changes, and do your refac­tor­ing at your own pace (or not at all).

  4. Inter­est­ing post, Peter

    I guess you mean to say “than the abstrac­tions of PRE-proces­sors like Sass”; not post.

    Francisco Blanchart [May 29th, 2015, 08:50]

  5. Thanks every­one, these are real­ly good insights, have helped me a lot. This is exact­ly the rea­son I keep com­ments on my blog.