Is It Time To Replace Sass?

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:

• file organization
• list and maps
• looping
• static variable overrides

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?

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.

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

• nesting - yup, covered during transpiling as long as you enable the nesting option or include the CLI flag
• compile from separate files - yes, uses the @import syntax and already supports defining imports as layers!
• static variables - not without a custom at-rule transform, but I've largely moved to use custom properties, so this would have low impact for most of my projects
• looping - no, but potentially possible to work out as a custom transform?
• lists and maps - no, and also not as useful without looping available
• mixins - again, mixins are possible via custom transforms and actually the example given in the docs
• complex custom functions - Sass is likely still going to win unless you want to build your functions in Node etc. first
• build integration - CLI and methods for Node and other build tools is available, as well as already being built-in to Parcel
• single-line comments - fans of // comments will have to stick to Sass for support OOTB (honestly, I will miss this, too)

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

• minification
• autoprefixing
• transpiling/"syntax lowering" of particularly nesting, media range queries, logical properties, and new color functions and features like relative color syntax

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.