A 13-Year Sass Habit, Reconsidered
When the topic of Sass came up in a recent Front End Study Hall session, I didn't get a chance to share my thoughts before the conversation moved on. That turned out to be a good thing, because it forced me to put together a proper answer in writing.
I've been using Sass since March 2012. I picked it up for a personal site redesign, starting with the SCSS syntax because it felt closer to vanilla CSS than the indented syntax did. At the time, Compass processed my files, and I used a GUI tool called Scout to run it without touching the command line. That simplicity is something I still appreciate, and it's a quality I find lacking in many of today's build setups.
Over the years, I used Sass in every agency job I've had. I liked variables for colors and typography, and nesting quickly became a habit because it grouped related rules together and let me write less code. I never went deep into the more advanced features like placeholder selectors or loops, and my use of mixins often meant pasting them from old projects and then forgetting they existed.
Earlier this year, I started building a personal memory-keeping app and made a deliberate choice to keep it simple: no build tools, just plain CSS. That intention lasted a couple of days before I realized I was writing nesting in my CSS — because native CSS nesting already works the way I was accustomed to in Sass.
That realization made me stop and ask: Is it finally time to un-Sass?
What Native CSS Already Covers
A lot of what originally made Sass attractive has been absorbed into CSS itself. Custom properties are a clear example. They go beyond Sass variables because you can update them in media queries, theming contexts like dark and light mode, and even from JavaScript. Sass compiles away its variables into static values, but custom properties live in the browser and participate in inheritance and scoping like any other CSS property.
Nesting is another big one. When Sass introduced it, the major win was seeing the relationship between parent and child selectors, and being able to keep media and container queries inside the selectors they apply to rather than scattered in far-flung sections of the stylesheet. Native CSS nesting now works much the same way, and one of the most welcome changes is that the syntax no longer requires an ampersand before an element selector, as some earlier drafts of the specification did.
There is at least one difference to note. You can't create concatenated selectors with nesting in native CSS. In Sass, you might write something like &__title to construct a BEM-style class name. That won't work in plain CSS, because the & is a live object and always treated as a separate selector. This never mattered to me, since I didn't use that style of concatenation in Sass, but developers who do will need to adjust.
For color manipulation, the color-mix() function offers parity with the Sass color module for lightening and darkening. In Sass, my hover colors often looked like darken($color, 10%). With color-mix(), the same result is available natively, and I've used it regularly in recent months. For instance, in a project with custom properties, I can mix a color variable with a fixed amount of white to get a hover state:
button {
&:hover {
background: color-mix(in oklab, var(--button-bg), white 10%);
}
}What Still Needs Work
Mixins and functions are the remaining gap. There's no native CSS equivalent yet, although the CSS Functions and Mixins Module is in progress. Where I depended on functions was mostly for calculations, like converting pixels to ems for media queries, which is better practice because em-based queries hold up to page zoom without breaking layouts.
With a base font size set to 100% (defaulting to 16px), you can replicate a pixel-to-em function using calc(). A custom media query for a minimum width of 600px would look like:
@media (min-width: calc(600 / 16 * 1em)) { ... }The Tooling Tax
My strongest motivation for un-Sassing is fatigue with tooling. Build systems have become more complex, not necessarily better, and much of the current tooling seems aimed at JavaScript-first or framework-based workflows. My needs are simpler, and I don't want a complex system for elementary tasks.
That frustration surfaced at work when I had to add new content to an older WordPress site. The codebase relied on CodeKit for compilation, and the repo settings were saving processed files to the wrong place. Once I fixed that, I hit more errors because Dart Sass introduced syntax changes that broke existing code. I spent about ten minutes trying to refactor before giving up and just writing the new CSS directly in the template.
Small frictions compound. Even in modern codebases, Sass has a habit of evaluating CSS as math when you don't want it to, like a minmax() value mixing percentages and pixels. It's a solvable problem, but it's time spent on tooling rules when I could have been writing actual HTML or CSS.
Depends on the Project
My verdict, disappointing as it may be, is: it depends.
For my personal site, the answer is yes. The codebase is small enough that an un-Sass effort would take a weekend. Removing the build process eliminates dependencies, and a nice side effect is that visitors can view the CSS source directly — useful when the whole point of the site is sharing code that might help others.
For the larger project I maintain at work, it's a different story. There is too much legacy code to refactor, and the cost can't be justified when the current pipeline works fine. Sass remains a solid tool; nothing about it is broken.
A Hybrid Path Forward
Changing technology doesn't have to mean tearing things down. Our codebase at work mixes Sass variables and custom properties without conflict. CSS built on earlier techniques, maintained backward compatibility, so old and new can comfortably coexist.
Everything we use today stands on what came before. We should evaluate our choices not by what we know now, but by what made sense then and whether it still does today. And no matter which tool you lean on, the goal stays the same: just build websites.
