Is It Time To Replace Sass?

Feb 25, 2023

I have used Sass for a very long time within marketing departments, design system teams, and on many solo projects. My standout reasons as expanded upon in this post were:

See how "nesting" didn't even make that list (even though it absolutely is a feature I'm accustomed to using)? Meanwhile, it seemed like a significant portion of my network heard "native CSS nesting is coming!" and immediately declared Sass was dead.

So... what is available in the meantime before nesting is fully stable and has significant browser support? And what other features do we miss out on by moving from Sass?

All In on LightningCSS

I became a fan of LightningCSS very soon after it was released. It's a parser for CSS that autoprefixes, minifies, and transpiles new CSS (including nesting) to accommodate your browser targets.

While I had already swapped to using LightningCSS primarily for minification and autoprefixing in my Eleventy Sass starter, including releasing a dedicated plugin, I recently evaluated if I needed Sass at all. You can also get the non-Sass LightningCSS Eleventy Plugin.

Feature Comparison

Your priorities may be different, but here is what I considered as features I would need to be supported in order to replace Sass.

Additional features that I find beneficial from switching to LightningCSS for CSS processing:

Will I Keep Using Sass?

Yes, but for a shrinking set of reasons which revolve around making large projects that are intended to have downstream customization (think: multi-brand/team design systems). Then again, I might nerd-snipe myself and make LightningCSS plugins to fill the gaps. Or perhaps... one of you reading will make them? Or point out a tool I haven't heard of yet?

I enjoy building or customizing my own tooling where needed, but if that doesn't appeal to you, then sticking with Sass may be the best option. Even then, you may find LightningCSS is a swap for stringing together multiple PostCSS plugins like it was for me.