uuid: - value: f98589c7-10e8-4903-b801-f2a42135b190 langcode: - value: en type: - target_id: daily_email target_type: node_type target_uuid: 8bde1f2f-eef9-4f2d-ae9c-96921f8193d7 revision_timestamp: - value: '2025-05-11T09:00:50+00:00' revision_uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 revision_log: { } status: - value: true uid: - target_type: user target_uuid: b8966985-d4b2-42a7-a319-2e94ccfbb849 title: - value: | How and why I started using PostCSS created: - value: '2022-12-09T00:00:00+00:00' changed: - value: '2025-05-11T09:00:50+00:00' promote: - value: false sticky: - value: false default_langcode: - value: true revision_translation_affected: - value: true path: - alias: /daily/2022/12/09/how-and-why-i-started-using-postcss langcode: en body: - value: |

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.

format: full_html processed: |

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.

summary: null field_daily_email_cta: { }