Why We Use PostCSS at Netguru

Feb 21, 2017 • 6 min read

PostCSS is a tool for transforming styles with JS plugins. These plugins can lint your CSS, support variables and mixins, transpile future CSS syntax, inline images, and more.

https://github.com/postcss/postcss#postcss---

How Does It Work?

PostCSS alone doesn’t do anything on its own. It parses CSS into an Abstract Syntax Tree (AST) represented in JSON and then stringifies it back into CSS. What enables its power are plugins which get the parsed version and can transform it freely with JavaScript. Here's a visual representation:

original.css -> Parser -> Plugins -> Stringifier -> output.css

Comparison with SASS

PostCSS can provide all the features that SASS has. There is even a package which does exactly that – it’s called PreCSS.

A nice thing about PostCSS is, however, that it can very well coexist with SASS. It can run after a SASS compilation, applying its transforms to the resulting CSS. This makes it very easy to integrate it even into SASS-heavy projects.

The new projects can use just the PostCSS with plugins providing SASS-like features, such as nesting or mixins. It allows us to replace SASS features found in new web standards, e.g. variables, and leave those available exclusively in SASS, such as nesting. This is beneficial because we can use as much CSS and as little other languages/syntaxes as possible, which would make it easier for developers not familiar with SASS.

Does It Require a Lot of Setup?

It depends. If your project already has Webpack/Gulp or some other JavaScript-y automatisation tool – good job, you're about 10 minutes away from having a working PostCSS installation. This will be the case most of the time since most projects already use some kind of automation for transpiling ES6 with Babel.

If it doesn’t have anything like that – sorry, you have to get one to use PostCSS.

Example config (using webpack):

// install postcss with autoprefixer

npm install --save-dev postcss autoprefixer

 

// add webpack loader

{

  key: 'style',

  test: /\.s?css$/,

  loader: ExtractTextPlugin.extract('css!postcss!sass')

}

 

// define plugins (in webpack's module.exports)

postcss: [

  require(‘autoprefixer’)

]

That’s it!

Keeping Our Stack Tight

As it’s very easy to add new plugins, it’s also difficult to enforce a single stack through many projects. If stacks differ, new developers need to learn new syntaxes and features, which may prove troublesome in the environment with a high turnover. This is both the greatest strength and drawback of PostCSS, looking from a company’s perspective.

PostCSS Pros:

allows for the usage of the most current web standards[7],
enables modular, more maintainable CSS[9],
allows picking a setup catered to one’s needs,
easy to write one's own plugins,
easy to add to the existing Webpack/Gulp/whatever setup,
can work alongside SASS[10],
faster compilation than SASS[11].

PostCSS Cons:

one more tool,
doesn’t support Rails Asset Pipeline[12],
requires a task runner/module bundler to work,
harder to maintain across different projects.

Conclusion

With great power comes great responsibility. PostCSS provides a set of extremely useful features that would make every CSS codebase more maintainable, and it can work alongside SASS or even replace it. Nonetheless, a company willing to adopt it needs solid agreements or a centralised configuration to make the setup consistent across a bunch of different projects and ensure effortless onboarding of new developers.