PostCSS Today: Its Pros and Cons

Today one of the hottest topics for debate focuses on what PostCSS really is: a postprocessor, a preprocessor, or something else, which, generally speaking, doesn’t have a particular significance. Summarizing all the existing viewpoints, we can say that PostCSS is a tool for transforming the initial CSS with JavaScript plugins (i.e. processors). At the moment, PostCSS is applied in one form or another in numerous large companies such as Facebook, Google, Github, etc. Besides, a lot of developers are already using PostCSS without even realizing this fact. For example, Autoprefixer that is quite common in the front-end development is the most well-known PostCSS processor.

In fact, work with PostCSS consists in choosing the required set of processors that extend the functionality of the plain CSS far beyond the framework set by the current specification version. If the required plugin can’t be found, then it’s possible to implement it independently with JavaScript. At the moment, the list of the most popular plugins includes not only full (postcss-less-engine) or partial (Precss) alternatives to the most common preprocessors but also more complex ones.

The PostCSS Sprite plugin automatically merges separate images into sprites and generates relative styles. When other plugins are used, developers can forget about such routine operations as adding the required fonts in case of applying postcss-font-magician. The control over the position of assets can be given to the postcss-assets processor that among other things will calculate dimensions of images and after that will add them to stylesheets, if needed. Stylelint proofreads and validates the code based on the specified conditions. Besides, it can check not only the plain CSS but also SCSS. Doiuse provides information on support of various properties in the specified target browsers utilizing data from Can I Use, and the previously mentioned Autoprefixer will add prefix properties to support old browsers based on the same database.

However, PostCSS has its shortcomings due to its modular structure, which leads to problems with syntax highlighting in the popular IDE. Although this direction is being actively developed now (there are plugins for Sublime Text and Atom, the plugin for WebStorm is being developed now), it is often more convenient to use the *.scss or *.less files for stylesheet storage.

The downside of scalability is the duplication of functionality, since the PostCSS core doesn’t determine the syntax, plugins introducing similar functionality can be simultaneously used. For example, it is often possible to find postcss-custom-properties and postcss-simple-vars in dependencies of more complex plugins. Both processors provide functionality with variables, in particular, the first processor uses syntax specified by the W3C specification for the future CSS versions, and the second one uses the SCSS syntax.

The first option is more preferable, and probably one day it will become the standard in CSS, but it is required to use the second option if applied in mixins.

Besides, not all plugins behave in an expected way, postcss-mixins doesn’t allow commenting a code when mixins are used. Precss designed to write a code in the SASS style in many respects repeats the behavior of the relative constructions from SCSS. For example, the @each operator looks more restricted as compared to the SCSS-original, and can’t work with a key, although the other @each operator successfully copes with this task. However, as we can see, there again occurs duplicating of functionality, already from the postcss-each processor.

In other words, PostCSS is a powerful tool which allows developers to considerably reduce volumes of the source code and at the same time avoid using additional tools for operation with assets, analysis, prefix properties, minification, etc.

Most problems are related to syntax plugins, such as Precss and postcss-cssnext, but developers are free to use other opportunities of PostCSS and apply SASS, LESS, and Stylus for preprocessing as they have already showed good performance.

As for the prospects of using PostCSS in commercial projects, we can note that it is an excellent choice for writing new apps and integrating into the already existing apps that don’t use preprocessors. In case of transition to PostCSS from any preprocessor, complexity and labor costs will be proportional to the utilized resources of the preprocessor. And what if such a large project like Bootstrap will soon shift to PostCSS (https://twitter.com/mdo/status/591364406816079873), then I would ask: and what about you?

Useful links:

http://postcss.org/ – an official website of the project

https://github.com/postcss/postcss – a project repository on GitHub

http://postcss.parts/ – a collection of PostCSS plugins

http://webdesign.tutsplus.com/tutorials/postcss-deep-dive-create-your-own-plugin–cms-24605 – an article about writing the PostCSS plugin

http://cssnext.io/ – a plugin introducing syntax constructions from future CSS versions to PostCSS