Native CSS nesting, goodbye to Sass

Sass had been in my workflow for so long that installing it was almost a reflex at the start of any project, without stopping to think whether I actually needed it. With native nesting now supported in every modern browser, on the projects I’ve started this year I simply haven’t installed it again.

The only thing I actually used from Sass

Honestly, out of everything Sass offers — variables, mixins, functions, loops — the only thing I used in ninety percent of my files was nesting: being able to write .card { .title { ... } } instead of repeating .card .title { ... } as a flat selector every time. I replaced variables years ago with CSS custom properties (--color-brand), which also have the advantage of being able to change at runtime depending on context, something a Sass variable could never do because it disappears at compile time.

With nesting now native, the one piece I was missing to drop Sass entirely stopped being missing.

What I gain by removing it

One less step in the build. Without Sass there’s nothing to compile — the browser understands nested CSS directly, so the file I write is literally the one that gets served. That means one less dependency to keep updated, one less postcss.config, and when debugging in dev tools there’s no longer that gap between the generated CSS and the original .scss file.

What I do miss a little

The loops and functions for generating variations of a scale (for example, spacing-1 through spacing-10 from a formula) I do miss from time to time. For that I still write those values by hand in CSS variables, which in practice aren’t so many that it’s worth dragging along a whole preprocessor just for that part.

I’m not going to rip Sass out of older projects that already have it well integrated — there’s no point migrating just for fashion’s sake. But on everything new, native CSS already does what I need without asking me to install anything extra.