SCSS or SASS; is it still relevant?

Last time I wrote about BEM, where it came from, how it’s used, and whether it still has any relevance today. In this post, I want to do something similar, but this time for SCSS/Sass.

What is SCSS/Sass?

SCSS/Sass is an extended CSS language library and a CSS preprocessor. It has multiple features that help with writing consistent, more readable, and reusable CSS.

What's the difference between SCSS and SASS?

Sass and SCSS both use the same tool to preprocess CSS. The precompiler is actually named Sass, and it can consume both .sass and .scss files.

.scss is essentially extended CSS syntax. This means you can write regular CSS, and it will work perfectly fine.

.sass, on the other hand, uses indentation instead of curly braces to define properties for a selector. This differs from standard CSS syntax, so you can’t write regular CSS in a .sass file.

What features does Sass have?

There are many features, but let me describe a few that are used frequently:

1. Nested selectors

One of the most commonly used features is the ability to nest selectors. You can write:

.header {
  .logo {
    background: hotpink;
  }
}

Instead of:

.header .logo {
  background: hotpink;
}

This might seem like a minor convenience, but in a large codebase, it can make a big difference. Some developers feel they can’t work without it, while others find it outdated, especially with component-driven development and scoped styling.

2. Mixins

You can create reusable code blocks (similar to functions) that accept parameters and generate repeated styles with minor differences:

@mixin node($color) {
  border: 1px solid $color;
  background-color: rgba($black-40, 0.5);
  box-shadow: 0 0 0 0 rgba($color, 0);

  &.selected {
    background-color: rgba($color, 0.5);
    box-shadow: 0px 4px 12px 0px rgba($color, 0.5);
  }

  .icon {
    color: $color;
  }
}

3. Variables

You can define variables that can be reused throughout your styles:

$black: #000000;
$black-80: #231f20;
$black-60: #292929;
$black-40: #363636;

In most cases, you can now use native CSS variables for the same purpose. I can't think of many use cases for this feature that aren’t possible with modern CSS.

4. Parent selector

Sass includes a parent selector (&) that references the current selector. This is especially powerful when combined with BEM-style naming:

.button {
  background: $black;

  &:hover {
    background: $black-60;
  }

  &--large {
    font-size: 18px;
  }

  &.active {
    background: hotpink;
  }
}

5. Imports

You can import other Sass files, making it easy to split large stylesheets into smaller, reusable modules:

@import 'variables';
@import 'buttons';

Note that CSS also has @import, but it typically fetches styles at runtime, which can be slower due to additional network requests.

Relevance

Sass is quite old, it was created in 2006 to help structure CSS more effectively, especially in large codebases. It was built in a time when component-driven development wasn’t really possible, and when CSS lacked many of the features we now take for granted.

It’s still widely used, particularly in component frameworks like Vuetify and Quasar. Sass usage remains strong and stable (see the State of CSS results from last year), and in some cases it's even increasing (see the number of npm downloads).

Conclusion and my opinion

I really liked Sass back in the day. It finally allowed me to split up huge CSS files into more modular ones. Being able to use variables was awesome—no more designers breathing down my neck about slightly off colors, and no more massive refactors just to change a single shade. Even mixins were great when used properly.

However, many of Sass’s features have since been adopted into the CSS standard. For example, CSS variables have been supported in all major browsers for quite some time now. And with modern web development becoming increasingly component-driven, CSS is naturally more modular anyway.

As for the nesting feature, I’ve always had a love-hate relationship with it. On one hand, it’s great to nest selectors without repeating the same strings over and over. On the other hand, excessive nesting can lead to overly specific selectors and deeply nested code that’s harder to debug—especially when trying to trace a class from the DOM that was compiled from a nested structure.

In practice, I find the long-term benefits of using Sass aren’t always worth the trade-offs. That’s partly because I tend to prefer native standards over tools that compile into them. It’s also because using Sass adds another compiler to the build pipeline, another “language” to learn, and another dependency to maintain (even if Sass itself rarely has breaking changes).

So for me, I prefer to use vanilla CSS when possible.

What about you? I’d love to hear your thoughts on Sass—its features, and its place in the future of web development.