Thinking About Ditching CSS Pre- and Post-Processors?

Once upon a time, CSS lacked many of the features developers needed, which led to the rise of tools designed to make writing CSS easier. Over the years, these tools have generally fallen into two categories: pre-processors and post-processors.

Pre-processors, such as Sass, Less, and Stylus, allow developers to write styles in an extended syntax that is then compiled into standard CSS. Post-processors, on the other hand, take CSS written in a slightly enhanced or non-standard syntax and transform it into valid CSS after the fact.

Two major post-processors dominate the space today: PostCSS and the newer Lightning CSS. PostCSS has been around for a while and has become a staple in many developers’ toolchains, largely thanks to plugins like Autoprefixer, which automatically adds vendor prefixes to CSS properties.

Although modern browsers have become more consistent, making Autoprefixer less essential, it’s still widely used because it removes the need to worry about vendor-specific syntax.

Post-processors are increasingly winning the CSS compilation game, thanks to several key developments:

1. Native CSS has added many long-awaited features.
2. Tailwind CSS has dropped support for pre-processors.
3. Lightning CSS has emerged as a powerful, fast alternative.

Let’s explore these developments in more detail.

Native CSS Is Catching Up

Pre-processors became popular because native CSS lacked features like variables, nesting, modularization, conditionals, and mixins. However, CSS has come a long way. Today, variables and nesting are widely supported across modern browsers, significantly reducing the need for pre-processors.

Even more advanced features like the if() conditional function are on the horizon. For developers who only need variables and nesting, native CSS may now be sufficient. For modularization, tools like Sass’s use feature or PostCSS’s postcss-import plugin can still help break CSS into manageable parts. PostCSS also offers plugins for conditionals, mixins, and functions if needed.

Interestingly, Tailwind’s @apply feature can often replace traditional mixins, offering a utility-first approach to styling.

Tailwind CSS Moves Away from Pre-Processors

With version 4, Tailwind CSS officially dropped support for pre-processors like Sass, Less, and Stylus. According to its documentation, Tailwind should be treated as a complete CSS build tool and not used alongside other pre-processors. It handles nesting, variables, imports, and vendor prefixes internally.

If you install Tailwind using its recommended method, you won’t be able to use it with other pre-processors in the traditional way. For example, the standard @import ‘tailwindcss’ syntax is incompatible with Sass.

However, there is a workaround: you can still use Tailwind with Sass by importing individual Tailwind layers as CSS files, like so:

@layer theme, base, components, utilities;

@import “tailwindcss/theme.css” layer(theme);
@import “tailwindcss/utilities.css” layer(utilities);

This method is a bit more verbose and less intuitive, which may discourage developers from using pre-processors with Tailwind altogether. As Tailwind’s popularity grows, this could further reduce the use of pre-processors.

Enter Lightning CSS

Lightning CSS is a powerful post-processor that can replace much of the PostCSS ecosystem. It offers many built-in features and stands out for its exceptional speed. In fact, it can process over 2.7 million lines of CSS per second on a single thread, making it more than 100 times faster than JavaScript-based tools like CSS Nano.

This performance advantage is a major draw for developers looking to optimize build times. Plus, Lightning CSS integrates easily with popular tools like Vite. For example, you can configure it in your vite.config.mjs file like this:

// vite.config.mjs
export default {
css: {
transformer: ‘lightningcss’
},
build: {
cssMinify: ‘lightningcss’
}
};

If you still need additional PostCSS plugins, you can include Lightning CSS as part of the PostCSS toolchain:

// postcss.config.js
import lightning from ‘postcss-lightningcss’;

export default {
plugins: [lightning, /* other plugins */],
};

Many developers, including Chris Coyier, have adopted Lightning CSS for its simplicity and speed, opting for a streamlined CSS processing setup.

Should You Ditch Pre-Processors?

If you’re considering simplifying your CSS toolchain, here’s a quick guide based on your needs:

Use Native CSS if you only need:

– CSS Variables
– Nesting

Use Lightning CSS if you also need:

– Modular CSS via import statements

Use Tailwind (with @apply) if you need:

– All of the above
– Mixins

Stick with Sass if you still require:

– Advanced conditionals (if, for)
– Custom functions

While tools like postcss-for exist, they may