4 myths about PostCSS

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 familiar Sass and Less approaches. This rivalry has generated some misconceptions.

Let's dispel some of the most common PostCSS myths and see how you can improve your workflow with it.


If you want to know more about what PostCSS is and how to configure it, read the articleintroduction to PostCSS and come back to dispel myths!

Myth 1: PostCSS is a pre- or post-processor


Let's start with perhaps the biggest misconception related to PostCSS.

When PostCSS was just released, it was positioned as a "postprocessor." Most of the first PostCSS plugins took regular CSS and improved it somehow. This approach was different from preprocessing, in which a special syntax is compiled into plain CSS.

However, calling PostCSS a postprocessor is somewhat wrong, as it downplays its capabilities. I prefer to call it just a CSS processor, because with the help of plugins it can perform a variety of tasks and act at different stages of working with CSS.

Some PostCSS plugins take on a particular syntax and translate it into regular CSS, as if you were working with a regular preprocessor like Sass. An example is postcss-nested, which allows you to write nested selectors, as is done in Sass and Less. Other PostCSS plugins take regular CSS and extend it, as, for example, does the most famous PostCSS plugin - Auto Prefixer . It automatically adds browser prefixes to your styles.

There are PostCSS plugins that don’t 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, while Colorguard helps develop a single color palette in a project.

In addition to this, PostCSS parses both CSS and the SCSS syntax (and Less, approx. Translator ). This means that you can handle your PostCSS plugins..scssfiles. We will discuss how this is done in the next section.

So the first myth can be dispelled - PostCSS is neither a pre- nor postprocessor. This is a CSS processor that can process or analyze styles at various stages of your workflow.

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


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

I think this happened because the first PostCSS plug-ins were aimed at supporting the capabilities inherent in preprocessors: variables, conditional statements, loops and mixins. With the growth of the PostCSS community, an extensive set of plugins has emerged to introduce new features that distinguish PostCSS from preprocessors.

Therefore, although you can use PostCSS as an alternative to preprocessors, you can also expand the current toolbox 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 run my Sass files through Stylelint before compiling them into CSS. And after that, the resulting CSS is expanded by plugins like AutoPrefixer and postcss-assets , which add browser prefixes and embed graphics through data URIs. So your workflow might look something like this:

using PostCSS

In general, how you use PostCSS is up to you. If you want to use it with a separate CSS handler, please. And if you are completely comfortable 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 right now. The world of front-end tools is already too vast - why add another tool and make the build process more confusing? The question is logical, but you need to answer it yourself, depending on the projects you are working on.

You can already use PostCSS without knowing it yourself. If you use AutoPrefixer to add browser prefixes to CSS, then you are already using PostCSS. Autoprefixer is a PostCSS plugin that can be added to regular task runners like Grunt and Gulp through the plugins grunt-postcss or gulp-postcss . There are ways to do this for other tools, such as webpack — for more 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 plugins can simply be added to the AutoPrefixer at any time when you go to build them into your work.

If for some reason you are not using AutoPrefixer, look at the other available plugins . Each project and each development team are different from each other, and even if you simply scroll through the list of available plug-ins, you can find something useful there.

Adding PostCSS to your workflow is no more difficult than plugging in some Grunt or Gulp plugin. Don't neglect this just because another build step is added: if this step helps you improve your CSS experience, it's worth it.

Myth 4: PostCSS doesn't offer me anything my preprocessor can't


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

PostCSS has grown tremendously over the past year. Many new plugins have appeared, and the range of features offered by PostCSS has expanded significantly.

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

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

If you want to experiment with CSS Modules , then PostCSS will come in handy (since 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 to solve interesting CSS issues. Take a look at the catalog of available plugins at postcss.parts .

In general, PostCSS offers many unique features that are not available to other preprocessors. It is worth taking the time to familiarize yourself with them. You may find something that will allow you to easily expand 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 integrates quickly and offers convenient ways to work with CSS, preprocessors and coding.

If you have previously considered PostCSS and neglected it for any reason, I recommend that you reconsider your views. This is a tool that can improve any frontend development process.

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

Also popular now: