A few months ago one of the back-end developers ribbed me, "Front End Developers can't decide if they want to pre-process or post-process their CSS" after learning about PostCSS and CSSnext.

The worst part is he's right, but we've been doing both for some time unbeknownst to him. Unlike the hazier CSSNext ambition of bringing future CSS code today (based on PostCSS), PostCSS itself simply a library of tools for programmatically manipulating CSS with Javascript which is a zealous under-sale of the potential. Like any good front-end developer, I wanted to see if PostCSS made sense to use since I don't have the interest (yet) to use CSSnext.

While admittedly this isn't the most scientific test, I ran this using the current versions of gulp and grunt with their respective plugins using a rather large project build on a heavily modified version of Bootstrap 3. The result is roughly 9700 lines without minification, and a 160k CSS file minified. It's big, but it isn't massive either.

Grunt Results

Without PostCSS

  • Total 586ms

With PostCSS

  • Total 5.3s

Gulp Results

Without PostCSS

  • Total 388ms

With PostCSS

  • Total 4.75s

The configuration looks as follows:
Libsass -> autoprefixer -> minification.

In the grunt task, I have a watch task that triggers libass to grunt-autoprefixer to grunt-contrib-cssmin. I replaced the prefixing/cssmin with grunt-postcss.

For Gulp, the task was nearly identical, libass to gulp-autoprefixer to gulp-autoprefixer. I replaced the prefixing/cssmin with grunt-postcss. The result is pretty much the same.

What does this mean?

The takeaway is that previously modules that PostCSS replicates are considerably slower but (and I'll use bold to stress this) this does not mean you should not use PostCSS. PostCSS still has some serious potential if you're into eschewing the pre-processor for CSSNext or looking to use CSS Modules. However, unless you need PostCSS, you shouldn't feel obligated to replace current working tasks with the CSSnext version.