I Finally Dropped Sass From My Projects. Here's What Changed My Mind

I Finally Dropped Sass From My Projects. Here's What Changed My Mind.

I've had Sass installed in basically every project I've touched for the better part of ten years. It was just... there. Part of the setup script, part of the boilerplate, part of muscle memory. Nobody questioned it. You start a project, you run the install command, Sass goes in the toolchain, done.

Sometime in the last year or so I noticed I'd stopped actually needing most of what it gave me. Not all of it — I'll get to that — but most of it. And once I actually sat down and looked at why, it came down to a handful of CSS features that quietly matured while I wasn't paying close attention.

Variables, but actually in the browser

Sass variables were the first reason most of us reached for it in the first place. Centralize your colors, your spacing, your breakpoints, stop copy-pasting hex codes into forty different files. Genuinely useful, and for years CSS had nothing to compete with it.

:root {
  --button-padding: 10px 20px;
  --button-bg-color: #007bff;
  --button-text-color: #ffffff;
  --button-border-radius: 8px;
}

.button {
  padding: var(--button-padding);
  background-color: var(--button-bg-color);
  color: var(--button-text-color);
  border-radius: var(--button-border-radius);
  border: none;
  cursor: pointer;
  transition: background-color 0.3s;
}

The part that actually changed how I build things isn't that CSS caught up on syntax — it's that these variables are alive in the browser. A Sass variable gets baked into a static value the moment it compiles. A CSS custom property is still sitting there at runtime, which means JavaScript can read it, override it, and respond to it. Theme switching, per-component overrides, user-adjustable settings — none of that needed a rebuild step with plain CSS variables. With Sass you were compiling a snapshot. With custom properties you're shipping something that's still negotiable after the fact.

Nesting, without the preprocessor tax

This is the one that finally tipped me over. Nesting was Sass's whole personality for a lot of people — myself included.

.blog {
  position: relative;
  padding: 1rem;
  background: var(--neutral-100);

  .blog-item {
    border: 1px solid var(--neutral-200);

    & span {
      font-size: 1rem;
    }
  }
}

Native nesting landed in every major browser through 2023 and into 2024, and browser support is well past the point where I'd call it a gamble. Once nesting was off the table as a reason to keep the build step around, I genuinely couldn't come up with a second reason that outweighed "one less compiler in the pipeline."

:is() cleaned up my selector lists

I didn't expect this one to matter much when I first read about it, and then I started using it and haven't gone back.

:is(h1, h2, h3) {
  margin-block-end: 0.5em;
}

Anywhere I used to write out three or four near-identical selectors separated by commas, :is() collapses them into something that's actually pleasant to scan. Small thing, but small things add up over a codebase you're going to be staring at for years.

:has() — the one I didn't think we'd get

Selecting a parent based on what's inside it always felt like the thing CSS would never be allowed to do. It broke a mental rule I'd internalized: styles flow down, not up.

.hero:has(.hero-button) {
  background-color: var(--accent-50);
}

:has() breaks that rule on purpose, and it's fantastic. Conditional styling based on a component's actual contents, no JavaScript class-toggling required, no data attribute you have to remember to add and remove in sync with your markup.

Container queries changed how I think about responsive design

Media queries answer "how wide is the viewport." Container queries answer "how wide is the box this component is actually sitting in" — which, if you build reusable components that get dropped into sidebars, main columns, modals, and cards interchangeably, is almost always the question you actually wanted answered.

.parent-container {
  container-type: inline-size;

  .headline {
    font-size: 2rem;
  }

  @container (width >= 720px) {
    .headline {
      font-size: 2.5rem;
    }
  }
}

A component can now genuinely not care where it's rendered. It just responds to the space it's given. That's a bigger shift in how I structure a component library than anything Sass ever offered.

Cascade layers instead of specificity Tetris

If you've ever added an ID selector or stacked three classes together purely to win a specificity fight, you know the pain @layer is solving.

@layer utilities {
  .button {
    padding: 0.5rem;
  }

  .button--lg {
    padding: 0.8rem;
  }
}

Layers let you declare priority order explicitly — resets, then a framework, then your components, then your utility overrides — instead of fighting the cascade by piling on selector weight. It's not glamorous, but it removes an entire category of "why isn't this style applying" debugging sessions.

So is Sass actually dead?

No, and I want to be honest about that instead of pretending otherwise for a punchier ending. Mixins and functions are still genuinely better in Sass — the pixel-to-rem conversion function alone has saved me hours over the years, and there's no native CSS equivalent for arbitrary computed logic like that. If your project leans hard on those, dropping Sass is a real trade-off, not a free win.

What changed for me isn't "Sass is bad now." It's that the default flipped. I used to install Sass automatically and only skip it if I had a specific reason not to. Now I start with plain CSS and only reach for a preprocessor if the project genuinely needs mixins or functions Sass still does better. For most marketing sites, most component libraries, most of the client work that crosses my desk — that reason just doesn't come up anymore.

One less build step, one less thing to configure, one less dependency to keep updated. For a lot of projects, that's worth more than what Sass used to give me.

---

We're ArtClick, a web development agency based in Kyoto. We build company websites, WordPress sites, and custom systems — with a focus on sites that are fast, well-designed, and easy to maintain long-term. Learn more at artclickdev.com.