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 write down over time.

These methods can principally be categorized into two teams:

1. Pre-processors
2. Publish-processors

Pre-processors embody 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 approach — 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 discuss them each in a bit.

I feel post-processors have gained the compiling sport

Publish-processors have all the time been on the verge of profitable since PostCSS has all the time been a essential device 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 need to take care of 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 one needs 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 consists of:

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

Let me develop 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 have been crucial for many builders, together with:

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

Native CSS has progressed loads over time. 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 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 characteristic — the flexibility to interrupt CSS into a number of information. This may be executed with Sass’s use characteristic or PostCSS’s import characteristic (supplied by the postcss-import plugin).

PostCSS additionally incorporates plugins that may provide help to create conditionals, mixins, and capabilities must you want them.

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

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 device 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 purpose 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 methodology, 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, (luckily), Sass allows you to import CSS information if the imported file incorporates the .css extension. So, for those who want to use Tailwind with Sass, you possibly can. Nevertheless it’s simply going to be a bit of 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 types so I exclude them from my information.

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

Both approach, many individuals gained’t know you possibly can proceed to make use of pre-processors with Tailwind. Due to this, I believe pre-processors will get much less standard as Tailwind good points 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 device chain together with:

Moreover having an honest 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 could actually 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 occasions. 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 for those who need assistance.

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

In the event you want different PostCSS plugins, you may also embody that as a part of the PostCSS device 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 will be assured that you’re most likely not stepping in any toes for those who want to swap to Lightning, too.

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

You’ll must examine the options you want. Native CSS is sufficient for you for those who want:

• CSS Variables
• Nesting capabilities

Lightning CSS is sufficient for you for those who want:

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

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

In the event you nonetheless want conditionals like if, for and different capabilities, it’s nonetheless finest 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 at this time. I hope it helps you when you’ve got been desirous about your CSS toolchain.