Although in the last years, working with preprocessors has been an undeniable advantage for frontend developers, they include certain disadvantages:
They are not extendable: none of them are limited to their own in such a way that if you need what is not included, you’ll have to add it as a separate step in your construction process.
They push out CSS standards: it could be said that each preprocessor has become a standard per se. This means that it goes on the way of no longer being compatible anymore with the new W3C standards, as in the case of polyfills.
One of its advantages is that there are no limits because it comes to an open community where we can create and collaborate with our own plugins for anything we want; if you can think it, you can write it.
postcss.parts - We can find all the plugins that there are already developed and the possibility of adding our own. Now there are more than 200 plugins and expanding, which means that they are versatile.
Thanks to its modularity, we only have to load and use what is necessary. Each plugin is installed separately because they are developed for very concrete functionalities. Furthermore, this is reflected in the fact that they are three times faster.
It doesn’t require its own syntax like sass or less, not even to translate the project into different languages.
Why use PostCSS now? Because we can use the W3C specifications now, so in the moment we get back to current projects, we can remove PostCSS and it will work because the browser will be able to interpret it.
Examples of more common PostCSS plugins:
Firefox and Google Chrome are already able to interprete this variables.
Although Sass and PostCSS for now are compatible, there will be a moment when we’ll have to let go of Sass. On account of that, we have the possibility of configuring PostCSS to develop like it should be Sass, and in this way the process of change would be less complicated.
PreCSS is a tool that joins together all the Sass possibilities with the future’s W3C syntax. Some of this plugins:
You can find here the complete list.
PostCSS is not a preprocessor per se, it goes beyond that. The name gets confused because although there are plugins to use as preprocessors and it is compatible to use a preprocessor and PostCSS on the same project. It also isn’t a tool for using and cleaning code, although once more also there are plugins to do it.
Although there is “post” in its name, it is not a “post-processor” either. The post processing can be understood as the comparison of an ended stylesheet to compare and validate the syntax of the CSS standards and do something as for example add vendor prefixes. Perhaps the name of “processor” could be more appropriate.
PostCSS is not “Future Syntax”, although there already are excellent plugins that allow writing in future syntax, they aren’t completely supported.
As a frontend from London described, PostCSS is as “a Swiss army knife for CSS production”.