So, You Wish to Give Up CSS Pre- and Publish-Processors…

There was as soon as upon a time when native CSS lacked many important options, leaving builders to provide you with all kinds of how to make CSS simpler to jot down through the years.

These methods can principally be categorized into two teams:

1. Pre-processors
2. Publish-processors

Pre-processors embrace instruments like Sass, Much less, and Stylus. Like what the class’s title suggests, these instruments allow you to write CSS of their syntax earlier than compiling your code into legitimate CSS.

Publish-processors work the opposite manner — you write non-valid CSS syntax right into a CSS file, then post-processors will change these values into legitimate CSS.

There are two main post-processors right this moment:

PostCSS is the biggest child on the block whereas Lightning CSS is a brand new and noteworthy one. We’ll speak about them each in a bit.

I believe post-processors have gained the compiling recreation

Publish-processors have all the time been on the verge of successful since PostCSS has all the time been a crucial instrument within the toolchain.

The obvious (and most helpful) PostCSS plugin for a very long time is Autoprefixer — it creates vendor prefixes for you so that you don’t must cope with them.

/* Enter */
.selector {
  remodel: /* ... */; 
}

.selector {
  -webkit-transform: /* ... */;
  remodel: /* ... */;
}

Arguably, we don’t want Autoprefixer a lot right this moment as a result of browsers are extra interopable, however no one desires to go with out Autoprefixer as a result of it eliminates our worries about vendor prefixing.

What has actually tilted the steadiness in direction of post-processors contains:

1. Native CSS gaining important options
2. Tailwind eradicating assist for pre-processors
3. Lightning CSS

Let me broaden on every of those.

Native CSS gaining important options

CSS pre-processors existed within the first place as a result of native CSS lacked options that had been vital for many builders, together with:

• CSS variables
• Nesting capabilities
• Permitting customers to interrupt CSS into a number of recordsdata with out extra fetch requests
• Conditionals like if and for
• Mixins and features

Native CSS has progressed rather a lot through the years. It has gained nice browser assist for the primary two options:

With simply these two options, I believe a majority of CSS customers gained’t even want to fireside up pre-processors or post-processors. What’s extra, The if() perform is coming to CSS sooner or later too.

However, for the remainder of us who must make upkeep and loading efficiency a precedence, we nonetheless want the third function — the flexibility to interrupt CSS into a number of recordsdata. This may be achieved with Sass’s use function or PostCSS’s import function (offered by the postcss-import plugin).

PostCSS additionally accommodates plugins that may provide help to create conditionals, mixins, and features do you have to want them.

Though, from my expertise, mixins might be higher changed with Tailwind’s @apply function.

This brings us to Tailwind.

Tailwind eradicating assist for pre-processors

Tailwind 4 has formally eliminated assist for pre-processors. From Tailwind’s documentation:

Tailwind CSS v4.0 is a full-featured CSS construct instrument designed for a selected workflow, and isn’t designed for use with CSS pre-processors like Sass, Much less, or Stylus. Consider Tailwind CSS itself as your pre-processor — you shouldn’t use Tailwind with Sass for a similar cause you wouldn’t use Sass with Stylus. Since Tailwind is designed for contemporary browsers, you truly don’t want a pre-processor for issues like nesting or variables, and Tailwind itself will do issues like bundle your imports and add vendor prefixes.

In case you included Tailwind 4 through its most direct set up technique, you gained’t be capable of use pre-processors with Tailwind.

@import `tailwindcss`

That’s as a result of this one import assertion makes Tailwind incompatible with Sass, Much less, and Stylus.

However, (happily), Sass helps you to import CSS recordsdata if the imported file accommodates the .css extension. So, when you want to use Tailwind with Sass, you’ll be able to. But it surely’s simply going to be a little bit bit wordier.

@layer theme, base, elements, utilities;

@import "tailwindcss/theme.css" layer(theme);
@import "tailwindcss/preflight.css" layer(base);
@import "tailwindcss/utilities.css" layer(utilities);

Personally, I dislike Tailwind’s preflight kinds so I exclude them from my recordsdata.

@layer theme, base, elements, utilities;
@import 'tailwindcss/theme.css' layer(theme);
@import 'tailwindcss/utilities.css' layer(utilities);

Both manner, many individuals gained’t know you’ll be able to proceed to make use of pre-processors with Tailwind. Due to this, I believe pre-processors will get much less in style as Tailwind features extra momentum.

Now, beneath Tailwind is a CSS post-processor referred to as Lightning CSS, so this brings us to speaking about that.

Lightning CSS

Lightning CSS is a post-processor can do many issues {that a} trendy developer wants — so it replaces a lot of the PostCSS instrument chain together with:

In addition to having a good set of built-in options, it wins over PostCSS as a result of it’s extremely quick.

Lightning CSS is over 100 occasions quicker than comparable JavaScript-based instruments. It may well minify over 2.7 million traces of code per second on a single thread.

Velocity helps Lightning CSS win since many builders are velocity junkies who don’t thoughts switching instruments to attain decreased compile occasions. However, Lightning CSS additionally wins as a result of it has nice distribution.

It may be used immediately as a Vite plugin (that many frameworks assist). Ryan Trimble has a step-by-step article on setting it up with Vite when you need assistance.

// vite.config.mjs
export default {
  css: {
    transformer: 'lightningcss'
  },
  construct: {
    cssMinify: 'lightningcss'
  }
};

In case you want different PostCSS plugins, you may also embrace that as a part of the PostCSS instrument chain.

// postcss.config.js
// Import different plugins...
import lightning from 'postcss-lightningcss'

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

Many well-known builders have switched to Lightning CSS and didn’t look again. Chris Coyier says he’ll use a “tremendous primary CSS processing setup” so that you might be assured that you’re most likely not stepping in any toes when you want to swap to Lightning, too.

In case you wanna ditch pre-processors right this moment

You’ll must test the options you want. Native CSS is sufficient for you when you want:

• CSS Variables
• Nesting capabilities

Lightning CSS is sufficient for you when you want:

• CSS Variables
• Nesting capabilities
• import statements to interrupt CSS into a number of recordsdata

Tailwind (with @apply) is sufficient for you when you want:

In case you nonetheless want conditionals like if, for and different features, it’s nonetheless greatest to stay with Sass for now. (I’ve tried and encountered interoperability points between postcss-for and Lightning CSS that I shall not go into particulars right here).

That’s all I wish to share with you right this moment. I hope it helps you in case you have been occupied with your CSS toolchain.