Is Sass still necessary?

The short answer: learning Sass has dropped down the priority list. The reason is simple—variables and nesting, Sass’s main selling points, can now be written in plain CSS.

But “not required” and “not worth knowing” are different. It’s still widely used in existing work, so you do want to be able to read a .scss file. This article sorts out what plain CSS absorbed and what remains Sass-only.

What Sass was solving

Sass spread as a tool that filled four gaps in CSS.

• Variables—give colours and spacing names, and manage them in one place
• Nesting—write parent-child relationships as nested blocks
• @mixin—give a chunk of declarations a name and reuse it
• File splitting—split by component, then emit one CSS file

CSS at the time could do none of it, so on larger sites Sass was practically mandatory.

The first two are plain CSS now

Variables (custom properties)

:root {
  --main-color: #ff8a3d;
  --space: 16px;
}
.button {
  background: var(--main-color);
  padding: var(--space);
}

Sass’s $main-color corresponds to plain CSS’s --main-color. And plain CSS variables can do things Sass variables can’t.

• They can be overridden later—dark mode or theme switching can swap just the variable’s value
• JavaScript can read and write them—you can change values while the page runs

Sass variables are resolved at build time and then gone, so neither is possible. On this point plain CSS is stronger—that’s the honest assessment today.

Nesting

.card {
  padding: 16px;

  .title {
    font-size: 20px;
  }

  &:hover {
    background: #fff3ea;
  }
}

That’s plain CSS. It works with no Sass at all. Being able to nest removes another reason to reach for Sass.

What Sass is still better at

Some features haven’t landed in plain CSS. This is why people keep using it.

The ones that really earn their keep are @mixin and @each. “Use the same chunk of declarations in ten places,” “generate twenty classes from a list of colour names”—Sass does those in a few lines. The bigger the codebase, the more Sass is worth.

How to read a .scss file

Just the things worth knowing when you meet one in an existing project.

$ is a variable

$main-color: #ff8a3d;

.button {
  background: $main-color;
}

The equivalent of plain CSS’s var(--main-color). See $, think “variable.”

& is “the parent selector itself”

.card {
  &:hover { ... }      // → .card:hover
  &.is-open { ... }    // → .card.is-open
  &__title { ... }     // → .card__title  ← the form plain CSS lacks
  .title & { ... }     // → .title .card
}

Only the third—joining class names—is missing from plain CSS. Not knowing it makes “where is this class name even defined?” untraceable.

@include is “call a chunk”

@mixin card-shadow {
  box-shadow: 0 2px 8px rgba(0, 0, 0, 0.1);
  border-radius: 12px;
}

.card {
  @include card-shadow;   // the chunk above is expanded here
}

See @include, and go find the @mixin of the same name to see the contents.

@use is “load another file”

@use 'variables';
@use 'mixins';

A file-splitting declaration. A file whose name starts with an underscore, like _variables.scss, means “a part that isn’t emitted on its own”—so that’s where the variable definitions live.

Using Sass means adding a build

This is the biggest practical difference. Browsers can’t read .scss, so you need a step that converts it to CSS.

That means “save and reload the browser” no longer covers it, and something has to run the conversion. That extra step is exactly why a beginner can leave Sass for later.

Deciding whether to use it

“Fewer reasons to choose it new, but alive in existing work”—a similar position to jQuery. Unlike jQuery, though, Sass is still sometimes chosen for new work (at scale, where @mixin pays off).

Summary

1. Sass’s main selling points—variables and nesting—are writable in plain CSS
2. CSS variables can be overridden later and read from JS—stronger than Sass here
3. Sass still wins on @mixin, @each, and &__title joining
4. To read .scss: “$ is a variable, & is the parent, @include calls a chunk”
5. Sass needs a build—which is why a beginner can leave it for later

Widening what you can write in plain CSS builds more skill than adding tools. Sass will wait until the day you actually need it.