4 PostCSS Myths

You are reading a translation of the PostCSS Mythbusting: Four PostCSS Myths Busted article.

When a new front-end tool appears, we always ask - do we need it, what new can it offer? Is it worth the time and effort to study it?

From the very beginning, PostCSS ran into an interesting problem. People did not understand what it was and how to use it. To gain attention, PostCSS had to compete with the already familiar approaches of Sass and Less. This rivalry has given rise to some misconceptions.
')
Let's dispel some of the most common PostCSS myths and see how you can improve your workflow.


If you want to know more about what PostCSS is and how to set it up, read the introduction to PostCSS article and come back to dispel the myths!

Myth 1: PostCSS is a pre- or postprocessor.

Let's start with perhaps the biggest misconception associated with PostCSS.

When PostCSS just came out, it was positioned as a “postprocessor”. Most of the first PostCSS plugins took plain CSS and somehow improved it. This approach was different from the preprocessor, in which the particular syntax is compiled into regular CSS.

However, calling PostCSS a postprocessor is in some way incorrect, since it diminishes its capabilities. I prefer to call it simply a CSS processor, since with the help of plug-ins it can perform various tasks and act at different stages of working with CSS.

Some PostCSS plugins take a special syntax and translate it into regular CSS, as if you were working with a regular preprocessor like Sass. An example of this is postcss-nested , which allows you to write nested selectors, as is done in Sass and Less. Other PostCSS plug-ins take regular CSS and extend it, as, for example, makes the most well-known PostCSS plugin - Autoprefixer . It automatically adds browser prefixes to your styles.

There are PostCSS plugins that do not transform your CSS at all. Instead, they analyze your code and suggest how to improve it. For example, Stylelint is used as a CSS linter, and Colorguard helps to develop a uniform color palette in a project.

In addition to this, PostCSS parses both CSS and SCSS syntax (and Less, approx. Translator ). This means that you can process your .scss files with PostCSS plugins. How this is done will be discussed in the next section.

So you can dispel the first myth - PostCSS is neither a pre- nor a postprocessor. This is a CSS processor that can process or analyze styles at various points in your workflow.

Myth 2: PostCSS - an alternative to preprocessors like Sass or Less

A common misconception among developers is trying to compare PostCSS with existing preprocessors, like Sass or Less.

I think this was due to the fact that the first PostCSS plug-ins were aimed at supporting the features inherent in preprocessors: variables, conditional statements, cycles, and mixins. With the growth of the PostCSS community, an extensive set of plug-ins has emerged that present new features that distinguish PostCSS from preprocessors.

Therefore, although you can use PostCSS as an alternative to preprocessors, you can also extend the current set of tools by adding new features to your favorite preprocessor.

PostCSS is suitable for parsing both CSS and SCSS syntax (and Less , approx. Translator ), which means that you can use PostCSS both before and after compiling Sass. For example, on the current project I use PostCSS to drive my Sass files through Stylelint before compiling them into CSS. And after that, the resulting CSS is expanded with plug-ins like Autoprefixer and postcss-assets , which add browser prefixes and embed graphics through data URIs. So your workflow might look something like this:



In general, how you use PostCSS is up to you. Want to use it as a separate CSS handler - please. And if you are completely satisfied with Sass or Less, remember that PostCSS can also work side by side with these tools, adding features that the preprocessor cannot do.

Myth 3: PostCSS will make configuration difficult

I know what you are thinking now. The world of frontend tools is too extensive - why add another tool and make the assembly process more complicated? The question is natural, but you need to answer it yourself, depending on the projects you are working on.

You can already use PostCSS without knowing it. If you use Auto Prefix for adding browser prefixes to CSS, then you are already using PostCSS. Auto prefixer is a PostCSS plugin that can be added to regular task runners like Grunt and Gulp via grunt-postcss or gulp-postcss plugins . There are ways to do this for other tools, such as the webpack — for details, see the PostCSS documentation .

If you have not used these plugins for Autoprefixer before, it's time to start. You will see how easy it is to connect other PostCSS plugins. For example, if I used Autoprefixer with Gulp, my code would look like this:

 return gulp.src( ['/**/*.css'] ) //  PostCSS   CSS  .pipe( postcss([ autoprefixer({ browsers: [ '> 5%', 'last 2 versions', 'ie > 7' ] }) //      … //     PostCSS- ]) ) .pipe( gulp.dest( CSS_DEST_PATH ) ); 

As you can see, additional plug-ins can be simply added to Autoprefixer at any time when you enter them in your work.

If for some reason you do not use Autoprefixer, look at other available plugins . Each project and each development team is different from each other, and even if you just scroll through the list of available plugins, you can find something useful there.

Adding PostCSS to your workflow is as easy as plugging in any Grunt or Gulp plugin. Do not neglect this just because one more build step is added: if this step helps you improve your work with CSS, it's worth it.

Myth 4: PostCSS does not offer me anything my preprocessor cannot

The essence of the myth is that PostCSS is directly compared with Sass and Less. Namely, consider plugins that emulate the functionality of Sass.

PostCSS has grown a lot over the last year. Many new plug-ins have appeared, and the range of features offered by PostCSS has expanded significantly.

If everything suits you in the current preprocessor and you haven’t used PostCSS before, because it offered the same thing, you should look at it again. Plugins such as Stylelint , postcss-stats and doiuse can provide automatic analysis of your CSS, which the usual preprocessor does not offer.

You can also optimize code: for example, minify SVG and CSS , provide more elegant backward compatibility with older browsers than mixins.

If you want to experiment with CSS Modules , then here you will need PostCSS (as this is just a set of plugins for PostCSS, approx. Translator ).

The main thing to remember when working with PostCSS is that it is still a relatively new tool. As the community grows, more plugins will be created that solve interesting CSS problems. Look in the catalog of available plugins on postcss.parts .

In general, PostCSS offers many unique features not available to other preprocessors. It is worth taking time to get acquainted with them. You may find something that allows you to easily extend the capabilities of your current preprocessor.

Total

PostCSS is a powerful CSS processing tool that can improve the workflow of any front-end developer. It is quickly integrated into the work and offers convenient ways to work with CSS, preprocessors and writing code.

If you have previously considered PostCSS and have neglected it for any reason, I recommend that you reconsider your views. It is a tool to improve any front-end development process.

Posted by: Ashley Nolan
Original article: http://www.sitepoint.com/postcss-mythbusting/