Some things you may think about PostCSS... and you might be wrong
I have recently tried PostCSS in my different workflows - Meteor workflow, simple React, and Webpack workflow. I knew I needed to try it because everyone is so excited to use it, and it did not disappoint me. You'll read about some thoughts I had of PostCSS before I learned what it was, so this is probably an article for people who don't use PostCSS yet.
Here are the things you may be thinking about PostCSS now:
- You probably think that this is a preprocessor replacement.
- You probably think that it's hard to add it into your current workflow.
- You probably don't know that you're already using it with the Autoprefixer plugin.
- You probably think that you don't need it.
- You'll probably love it if you use it.
I'll try to clarify this one by one. Of course, this is only my personal opinion, but many people could have similar thoughts.
You probably think that this is a preprocessor replacement.
Just remember that this isn't a preprocessor replacement, although it could replace it if you wanted it. For a great example, take a look at the PreCSS plugin pack. This is a toolset with many PostCSS plugins which can replace your Sass preprocessor.
If you got used to Stylus or Sass, you'd still be able to use it. After preprocessing, you can also use PostCSS processing with plugins.
You probably think that it's hard to add it into your current workflow.
You probably use some build tools like Gulp or Grunt, or Webpack. If so, you have to install the proper plugin for PostCSS. You will find Grunt tasks, Gulp tasks, and Webpack loaders for it. You can also use it in every NodeJS based API.
Many big companies also use it. It is integrated into many well-known frameworks and workflows. Just take a look at the list of runners. (For your interest, my Meteor package is listed there as well, so check it out!).
Usage is as simple as the usage of every preprocessor. It depends on your current workflow and tools stack, but it is very modular and flexible. You can choose only some of the plugins which you need. You don't need to install all features like preprocessors.
You probably don't know that you're already using it with the Autoprefixer plugin.
The funniest thing is that many people use Autoprefixer, and they don't know that. They are using PostCSS behind the scenes. This is a very common situation. Autoprefixer is used as a task for Grunt, Gulp, and other workflows and build systems. It is nothing else but another PostCSS plugin responsible for taking your CSS, checking its compatibility with browsers, and adding particular prefixes to your CSS declarations if needed. This is a perfect example of what your PostCSS plugins can do.
There are a couple of plugins for preprocessors that implement Autoprefixer. The most used are autoprefixer-stylus and less-plugin-autoprefix. What they do is make use of PostCSS and Autoprefixer plugins behind the scenes. You can check the 'package.json' file, and you'll find PostCSS and Autoprefixer dependencies there.
There were some simple polls about it, and this is quite funny, but many people still don't know that Autoprefixer is just a PostCSS plugin They are using it because it is awesome, and that's ok, but they still don't know what they can do with PostCSS and their plugins.
You probably think that you don't need it.
Many people think that they don't need it. They feel that they use Sass or Stylus, and that's all they need. I understand that because, in many cases, it's sufficient. But let's take a look at some use cases where the preprocessor is not enough.
Firstly, let's talk about the Autoprefixer plugin. It is an excellent tool that everyone uses, They don't know that they are using PostCSS, and that's ok, but this is a perfect example of how powerful PostCSS is and how such tools are needed right now.
The second example – Stylelint. Stylelint is an awesome PostCSS plugin that provides CSS linting tools and has many configuration options. You can configure many rules such as not using id or special class names configured by RegExp etc. Take a look at the Stylelint docs: http://stylelint.io/.
Third example – Lost Grid System. This is a very powerful grid system. It is written as a plugin for PostCSS. You can read more about it in the docs: https://github.com/corysimmons/lost. It is an example to show you how simple it is to extend your standard CSS syntax.
The last example is CSSNext. This is a cool toolset. With this PostCSS plugin, you can use future CSS4 syntax in your current apps. You can find all the cool features on the official website: https://cssnext.github.io/features/.
Also, if you use Sublime Text or Atom editors, there are excellent examples of using PostCSS for these editors. We have something like the PostCSS Sorting package for Sublime Text and also a version for Atom editor. It is a handy CSS rules sorter.
These are only some of the great examples that you can create with PostCSS. You can write your plugins, and you can also find many more on the Internet.
If you want to use just preprocessors, it's ok, but sometimes you need some more functionality in your app. I think that PostCSS is a tool that every developer should at least know the basics.
You'll probably love it if you use it.
We can stop using preprocessors because even now, there are many features from preprocessors implemented in PostCSS plugins. Of course, I know that many people like preprocessors very much. I am a huge fan of Stylus, and I love using it. But when I use PostCSS more and more, I sometimes think that I could stop using preprocessors completely. For now, I like using Stylus and PostCSS in one stack. It's cool. I'm not sure, but maybe soon I'll drop Stylus.
If you want to read more about PostCSS here are some useful links:
- PostCSS GitHub repo
- PostCSS official Twitter account
- PostCSS Deep Dive
- An Introduction to PostCSS
- Kick your CSS up a notch with PostCSS | ViennaJS 2015
- How to use CSS linter in Meteor
- PostCSS plugins list
Let me know your thoughts about PostCSS, and let me know if you are using it in your apps.