SASS

In short: A CSS preprocessor language — extends CSS with variables, nesting and functions, compiled into normal CSS before delivery.

In more detail: Plain CSS long had no variables or nesting — SASS (or its SCSS notation) filled this gap, by writing in an extended syntax that’s then compiled to standard CSS. Since CSS itself now supports native variables and, in part, nesting, SASS’s advantage has shrunk, but it remains firmly embedded in many existing projects.

In Depth

$primary-color: #1a1a1a;
 
.card {
  background: $primary-color;
  .title {
    font-weight: bold; // nested instead of .card .title { ... }
  }
}

SASS exists in two syntax variants: the original, indentation-based “SASS” syntax (without curly braces/semicolons) and the today considerably more common “SCSS” syntax, which looks like normal CSS, just with extra features — both compile to the same standard CSS. Beyond variables and nesting, SASS offers functions, mixins (reusable blocks of CSS rules with parameters), and inheritance between selectors, which native CSS still doesn’t fully offer today.

Because modern CSS engines now support their own variables (--custom-property) and, in part, native nesting, some of SASS’s original benefit has migrated into the language standard itself — new projects therefore reach for SASS less often than a few years ago, while many older, large codebases still build on it, and switching rarely justifies the effort.

Mixins and functions

A feature native CSS still doesn’t fully replicate today is mixins — reusable blocks of CSS declarations that can be called with parameters, similar to a function in a programming language:

@mixin flex-center($direction: row) {
  display: flex;
  align-items: center;
  justify-content: center;
  flex-direction: $direction;
}
 
.header { @include flex-center(row); }
.sidebar { @include flex-center(column); }

This considerably reduces repetition when the same combination of CSS properties is needed in many places with slight variations — a pattern native CSS only partly replicates with container queries and @property, but not with the same flexibility as SASS mixins.

The compile step as a build dependency

SASS’s central trade-off: since browsers only understand standard CSS, not SCSS, every SASS project needs a compile step (sass input.scss output.css) as part of the build process — an additional dependency and an additional step compared to plain CSS, which the browser can process directly. In modern frontend toolchains (Vite, Webpack, Next.js), this step is usually invisibly integrated into the existing build process, which keeps the practical overhead for developers low.

Relationship to utility-first frameworks

In recent years, utility-first CSS frameworks like Tailwind CSS have established an alternative approach that solves SASS’s basic idea (reusability, less repetition) differently — instead of writing your own CSS classes with SASS features, you combine many small, predefined utility classes directly in the HTML/JSX. Both approaches have active communities; the choice often depends on team preference and the existing codebase, not on one being objectively “better”.

See also: CSS, Bootstrap