DEV Community: NickdeK

SCSS or SASS; is it still relevant?

NickdeK — Mon, 14 Jul 2025 14:34:56 +0000

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.

Scoped Styling and the History of CSS Scoping

NickdeK — Tue, 24 Jun 2025 20:17:29 +0000

In my frontend development career of more than 10 years now (jeez, I’m old), I’ve come across a lot of frameworks, libraries, and languages. Recently, I had a discussion with some coworkers about why we should actually use Vue’s scoped styling feature. I figured it would be a good idea to write it down for future reference, and as my first blog post.

The scope of the discussion

The conversation started when I began working on a few projects that used SCSS with Quasar in Vue. None of the components used scoped styling. Instead, everything followed the BEM naming convention. It worked, but in my opinion, it was cumbersome. I was used to simply adding the scoped attribute to the <style> tag, no need for BEM, and I never had issues with styling bleeding into other parts of the build.

So that sparked a discussion: why were we still using these relics of the past in modern projects? Let me explain what my arguments were.

BEM

BEM (Block Element Modifier) was introduced in 2005, and I (kind of) started using it about five years later. It was created to solve a problem: in large projects, styling would unintentionally bleed into unrelated parts of the site. Scenarios like two developers using the same class name in different features were common, often resulting in styling bugs after merging code.

BEM introduced a structured naming convention based on blocks, elements, and modifiers, for example: .form-input--disabled. This helped reduce conflicts by encouraging unique, descriptive class names. More importantly, it forced developers to think about naming in a consistent and predictable way.

At the time, it worked well to reduce bugs and styling collisions. But personally, it never really clicked for me. While the concept made sense, in practice, I often struggled with deciding on names. It also added cognitive overhead, one more thing to remember and enforce.

Component driven development

About 7 or 8 years ago, I started working professionally with modern frontend frameworks. At the time, Polymer was gaining traction, and since it came from Google, my tech lead decided we’d give it a try. Polymer was Google’s vision for Web Components, and you could argue that it helped shape the standards we have today.

Like Web Components, Polymer used the Shadow DOM to render components. That meant each component had its own isolated DOM and scoped styles. CSS didn’t bleed in or out. And for the first time in my career, I could build five components, all with a .header class, and each would behave completely independently.

It was a revelation. I embraced component-driven development fully. Suddenly, I could build truly reusable components that I could copy and paste between projects and have them “just work” (well, mostly). I no longer had to think about naming things carefully to avoid conflicts. It was amazing.

Of course, it wasn’t perfect. There are cases where global styling is needed, and in the early days of Polymer, it was hard to style inside Shadow DOM boundaries. The ::part selector didn’t exist yet, so we often had to write CSS in JavaScript objects and pass them manually into components.

Scoped styling in Vue

Vue gives us the ability to add a scoped attribute to the <style> tag in single-file components. When you do this, Vue automatically generates a unique attribute (like data-v-xxxxxx) and scopes all your CSS to that component by prefixing selectors with that attribute.

It’s not as elegant as the native Shadow DOM model, but it gets the job done, and with fewer trade-offs. You can still use global styles when needed, and Vue provides the :deep() selector to let you style parts of child components or override library styles.

In my opinion, this eliminates the need for the often complex BEM naming convention. Scoped styles let you use clean, simple class names like .header, .button, or .list-item without worrying about conflicts or global pollution. And for me, that simplicity is very welcoming.

Conclusion

BEM was a great solution for a problem that existed in a different era of frontend development. But frameworks like Vue have changed the game. Scoped styles, whether through Vue’s system or the Shadow DOM, offer a cleaner and more maintainable way to write CSS in a component-based world.

You can still use BEM if it works for your team, but in many cases, scoped styles are simpler, more intuitive, and just as safe. It’s one less thing to think about, and for me that makes quite the difference.

What are your thoughts? Do you use scoped styling all the time or not at all? Please let me know in the comments below, I'm always happy to have some new insights 😊