You Probably Don’t Need to Use Sass For Your Site’s CSS Anymore

Even just five years ago, Sass was an essential part of my web development workflow. Sass — which stands for “Syntactically Awesome Stylesheets” — enhances and extends CSS, allowing you to use things like custom variables, code nesting, mixins and includes, and custom functions, all of which can make writing CSS easier and more efficient.

Development of CSS has continued at a steady rate, however, while browser support has continued to improve, meaning that modern CSS is pretty powerful in its own right. Which led Jeff Bridgforth to wonder, “Is it Time to Un-Sass?” After using Sass for many years, he began writing vanilla CSS in order to simplify a project, and was pleasantly surprised by what he found:

As I started building my prototype, I wanted to keep it simple. I didn’t want to have to set up any build tools. I decided to write CSS without Sass.

Okay, so that was my intention. But I soon realized that that I was using nesting. I had been working on it a couple of days before I realized it.

But my code was working. That is when I realized that the native nesting in CSS works much the same nesting in Sass. I had followed the discussion about implementing nesting in native CSS. At one point, the syntax was going to be very different. To be honest, I lost track of where things had landed because I was continuing to use Sass. Native CSS nesting was not a big concern to me right then.

I was amazed when I realized that nesting works just the same way. And it was in that moment that I began to wonder:

Is this finally the time to un-Sass?

Modern CSS now includes some of Sass’s killer features, including variables and nesting, while other features, like mixins, are on the drawing board (and will hopefully arrive in the not-too-distant future). What’s more, dropping Sass simplifies your workflow by reducing the number of tools and dependencies you need, which is always a good thing.

For those reasons, I’ve largely stopped using Sass for most projects, with little-to-no detrimental impact. I still use it for larger projects like design systems, though, mainly because Sass allows you to break up your CSS into smaller files (for individual components, widgets, layout elements, etc.) which can then be imported and compiled together into a single CSS file. This makes it much easier to organize and manage a large CSS codebase. When I need to update a single component’s styles, for example, I can just update its specific Sass file rather than wade through a massive CSS file and hope I find and update all of the relevant code.

That sort of code organization and management is a lot trickier to do without Sass. The closest un-Sassed CSS comes is the @import rule, which lets you import CSS files into another CSS file. However, @import can negatively impact a site’s performance, and should almost never be used. That leaves an external tool like PostCSS or Node.js as the only viable option, which also means re-introducing external tools and dependencies into your workflow.

If you’re a regular Sass user and can’t imagine web development without it, then I strongly recommend kicking it to the curb for a while and giving vanilla CSS a try, especially if the project in question is a simple site or personal blog. Like Bridgforth, you might just be pleasantly surprised by what you can still accomplish with a Sass-free workflow.