So, You Need 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 put in writing through the years.

These methods can largely 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 at this time:

PostCSS is the most important 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 received the compiling sport

Publish-processors have at all times been on the verge of profitable since PostCSS has at all times 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 should cope with them.

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

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

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

What has actually tilted the stability in the direction of post-processors consists of:

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 lots 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 received’t even want to fireplace 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 (supplied by the postcss-import plugin).

PostCSS additionally comprises plugins that may show you how to create conditionals, mixins, and features must you 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 particular 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 the event you included Tailwind 4 through its most direct set up technique, you received’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, (luckily), Sass allows you to import CSS recordsdata if the imported file comprises the .css extension. So, when you want to use Tailwind with Sass, you’ll be able to. However it’s simply going to be slightly bit wordier.

@layer theme, base, parts, 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 types so I exclude them from my recordsdata.

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

Both manner, many individuals received’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 standard as Tailwind positive factors extra momentum.

Now, beneath Tailwind is a CSS post-processor known 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} fashionable developer wants — so it replaces a lot of the PostCSS instrument chain together with:

Moreover 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 instances sooner than comparable JavaScript-based instruments. It may well minify over 2.7 million strains of code per second on a single thread.

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

It may be used straight 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 the event you want different PostCSS plugins, it’s also possible to 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 fundamental CSS processing setup” so that you might be assured that you’re in all probability not stepping in any toes when you want to swap to Lightning, too.

In the event you wanna ditch pre-processors at this time

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 the event 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 need to share with you at this time. I hope it helps you when you’ve got been enthusiastic about your CSS toolchain.