1.6 KiB
| title | pubDate | permalink | tags | ||
|---|---|---|---|---|---|
| How and why I started using PostCSS | 2022-12-09 | daily/2022/12/09/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.