How and why I started using PostCSS

I assume that, like many other Developers, when I started learning front-end development, I wrote normal, plain CSS and later discovered and adopted pre-processors like Less and Sass that added features such as variables and nesting to my stylesheets.

This was the case when I first saw what became Tailwind CSS, which were some stylesheets written in Less and ported manually between projects.

I remember watching one of those streams, and a fellow viewer suggested PostCSS, which Tailwind CSS would later be written in.

PostCSS, a CSS post-processor rather than a pre-processor, has become my preferred way of writing CSS because of Tailwind.

When I started using Tailwind in my projects, I was layering it on top of another CSS framework or styles that were written using Less or Sass, so I needed to pre-process them into CSS first and then run PostCSS - essentially running two build steps and adding to the build time.

I moved to use PostCSS by default - removing one of the build steps.

What I liked about it, as well as the quicker build times, was that I could start with plain CSS and add the extra features I needed. I didn't use all of Sass and Less' features, and now, if I needed nesting or real-time imports, I could add it via a PostCSS plugin or write my own.

It's also quick and easy to use, using the PostCSS CLI tool and without more complex tools like Webpack.

If you haven't tried PostCSS, I recommend taking a look.

- Oliver

Was this interesting?

Sign up here and get more like this delivered straight to your inbox every day.

About me

Picture of Oliver

I'm an Acquia-certified Drupal Triple Expert with 17 years of experience, an open-source software maintainer and Drupal core contributor, public speaker, live streamer, and host of the Beyond Blocks podcast.