Why I’m Making the Switch to PostCSS

And you should, too.

For the past few years, I’ve used Sass for CSS development. It’s tough to recall exactly when I adopted it into my workflow, but I remember the feeling. Variables? Awesome. Mixins? Yes, please! Partials, inheritance, and operations? Hell yeah.

I heard about PostCSS from various posts and most recently from a colleague. JavaScript-powered CSS processing. Whoa. I resisted adoption of PostCSS and its ecosystem of plugins out of stubbornness; why switch? Technically, I could use both Sass and PostCSS, but that defeats the selective benefit outlined below.

I’m making the switch to PostCSS for two reasons:

  1. Modular approach
  2. Ease of implementation

Modularity

When developing applications, there is notable benefit in isolating components. The separation of concerns is also applicable to CSS, particularly with processing.

Using Sass, you get the whole library of features at your disposal at once. Great! But what if you don’t use them all? With PostCSS plugins, you can select exactly which feature you want to to use, or even create your own.

Simple implementation

Getting started with PostCSS is as simple as installing the CLI or adjusting Gulp/Grunt files. Then it’s just a matter of writing the styles and invoking selected plugins when necessary.

I’m still a little wary to step away from Sass for the time being, but thankfully there’s a plugin to allow Sass-like syntax for PostCSS. Nice!

Like what you read? Give Andrew Tsao a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.