DEV Community

Goodbye SASS 👋, welcome back native CSS

Karsten Biedermann on March 20, 2024

Sass has established itself as a powerful preprocessor installed locally, forming the backbone of my projects for over a decade. It enabled me to e...

Read full post

Angela Caldas • Mar 20

I love pure CSS, but I still love using Sass for its mixins, functions and extends. Also, nesting in Sass is a little better than nesting in CSS when you use BEM in your projects, for example:

.block {
  // in Sass you would break the class name like this:
  &_element {
    // this would not work with CSS nesting
  }
}

But I am eager to be able to do this and more on CSS again! Thanks for the article!

Andrew Bone • Mar 21 • Edited

One thing I've starting doing in my code bases is replacing the M in BEM to use has where possible.

<button class="btn">
  <span>
    First Button
  </span>
</button>

<button class="btn btn--with-icon">
  <svg height="1em" width="1em">
    <!-- some svg code -->
  </svg>
  <span>
    Second Button
  </span>
</button>

/* tradition BEM */
.btn {
  background-color: tomato;

  /* this only works in SASS */
  &--with-icon {
    background-color: lime;
  }
}

/* BEM with has */
.btn {
  background-color: tomato;

  /* this works in vanilla CSS!! */
  &:has(> svg) {
    background-color: lime;
  }
}

I still use SASS and BEM commercially but these little steps closer to regular CSS can only be a win in my opinion.

Karsten Biedermann • Mar 21

This is a good example how you can transform from scss to css. Personally, I haven't used BEM for a long time. In general, I think it's good to break with conventions, especially when it obviously prevents you from trying something new.

Angela Caldas • Mar 21

Nice! Thanks for sharing this approach!

Thomas Bnt • Mar 20 • Edited

Yes! I'm still using SASS because BEM is powerful to write good code. But I will try CSS3 with news features likes @container and @layer, seems nice!

Angela Caldas • Mar 20

I definitely must try the features you mentioned since I've only read about them!

Massimo Artizzu • Mar 22

Many of the latest advancements in CSS help you ditch BEM for something much less verbose. Encapsulated styles (especially with @scope or a shadow DOM), or @layers, will definitely help you with that.

Karsten Biedermann • Mar 20

I agree! In some cases, it looks better in SASS, especially if you use BEM. As always, it's a compromise 😊.

Oluwafemi Durodola • Mar 25 • Edited

But will this work?

.block {
    //...
    .block_element {
        // ...
    }
  }

Angela Caldas • Mar 25

Yep, this works. The syntax I used doesn't.

Andrew Bone • Mar 27

The main different between these 2 is specificity.

.block {
  /* anything here has a specificity score of 10 */

  &__element {
    /* anything here has a specificity score of 10 */
  }
}

.block {
  /* anything here has a specificity score of 10 */

  & .block__element {
    /* anything here has a specificity score of 20 */
  }
}

Having higher specificity means things are harder to override later and, in some cases, leads to the dreaded !important

This example isn't too bad but the further you nest the more likely you are to have run away specificity.

Angela Caldas • Mar 27

Thanks for sharing this specificity issue, I wasn't aware!

András Tóth • Mar 20

I fully agree with you. However the more CSS can do from SASS the less any transpiler need to work, so the result will be closer to what you actually wrote. That's a good thing in my opinion.

Angela Caldas • Mar 20

Yeah, it is certainly a great thing, I agree with you, and I hope CSS gets even more powerful. I really enjoy using CSS, but at work, we still use Sass

András Tóth • Mar 21

Well it's a great tool, so it does not sound so bad as forced to write CSS-in-JS or to be barred from writing CSS because of a utility based framework.

Convergente Studio • Mar 27

Yeah, mixins are one of the best things on Sass, cuz this and other stuffs is why i still using even nowaday

Andrew Bone • Mar 20

I'm really looking forward to reusable functions and mixins. They're a little ways off yet but that doesn't stop the hype 😅

Future of CSS: Functions and Mixins

Andrew Bone ・ Feb 15

#css #webdev #future

Karsten Biedermann • Mar 20

Ohhh yes! That would be so great!

Convergente Studio • Mar 27

Oohhh the great Andrew Bone, such a famous person known in Twitter, yeah I really agree, but Sass still being a great, despite of new CSS modern in 2024

Rasmus Schultz • Mar 23

Modern CSS is awesome - but it's a bit late to say goodbye to SASS, I think.

By now, most software uses a component-oriented UI library of some sort (React, Svelte, Vue, Solid, etc.) and the question facing most developers isn't really SASS vs CSS anymore - it's more like SASS/CSS vs some sort of CSS abstraction... Emotion, Panda, StyleX, Tailwind, etc.

While CSS has caught up with most of the things we needed SASS for, the community has moved on from selectors to inline styling approaches, which just generally works better with components.

Remember when SASS was the brand new shiny, and the nested structure of SASS promised to nicely mirror the structure of the HTML elements? Of course, this turned out to be a bad idea, because you end up with compiled selectors that are way too specific, and everything quickly stopped doing it. It was a lot of the initial appeal though, I think.

By now, the easiest, most intuitive, most straight forward approach, is to put your styles directly on the elements in your components. No more dead selectors getting left behind. No more searching through the DOM in devtools trying to figure out what's changing the color of that button. Where is that rule that makes it bold on hover? It's right there, on the button element - it isn't accidentally matching anything else, it isn't being accidentally overridden by a more specific rule, and so on.

The choice between SASS and CSS is easier than ever before. Just choose. It's not that important.

But now there are dozens of libraries and approaches to CSS-in-JS, utility CSS generators, inline CSS libraries, and on and on - that choice is harder than ever.

(I wonder if CSS will ever catch up with the need for inline styling?)

Ben Halpern • Mar 20

I sign off on this

𒎏Wii 🏳️‍⚧️ • Mar 23

Does this mean Sass has become obsolete? Not at all. Mixins and functions, such as the conversion of pixels to rem, remain irreplaceable advantages of Sass

Irreplaceable? Far from it! Native CSS is getting functions and mixins too relatively soon; the discussion around the spec is still ongoing, but it is very unlikely to just die out. SASS will eventually just be obsolete.

Karsten Biedermann • Mar 23

Yes ❤️! github.com/w3c/csswg-drafts/issues...

András Tóth • Mar 20

Until we have what you said mixins, functions and extends we are missing one of the most important tool of clean coding: encapsulation of complexity. To be effective, you have to find the right properties that belong together and extract them into something meaningful, that is closer to the abstractions of the page.

But I do believe they can be incorporated into pure CSS. (As I think TypeScript at this point should be just there in browser, like how it works with deno).

eshimischi • Mar 21

Typescript won’t be in browser, because at the end it converts into JS, which is deno doing too. TS is just a superset

Dmitriy A. • Mar 20

:has() is great! We are using it for a while now.
Nesting is one of the most crucial part of SASS, not sure if cascading can replace it though 🤔

Karsten Biedermann • Mar 20

Maybe not replace it. I think some people will continue to use Sass. However, I believe it's beneficial to occasionally question the way we write CSS. There have been times when I found myself complicating things simply out of habit 😉.

Dmitriy A. • Mar 20

Agree, but SASS with proper linter is strict enough to keep CSS code streamlined

Shailen Naidoo • Mar 20

This is great but you would still need a preprocessor to ensure the newer version of CSS is backwards compatiable.

Andrew Bone • Mar 20

With browsers entering a new 'evergreen' phase this is becoming less and less of a problem. IE was an issue for a long time but with that gone most users will always be on, or close to, the latest release meaning we can improve our code bases at speed.

The new baseline initiative is a great rule of thumb, once it's green us that feature! 😅

Karsten Biedermann • Mar 20

That's exactly how I see it too @link2twenty

Miia • Mar 27

Great update!

Usually can't use SASS in my projects as it is not supported any more in the CMSs I use. And nice to know that nesting support in pure CSS starts to be on a level where it is acceptable to be used!

Sm0ke • Mar 21 • Edited

cool

Jaime López • Mar 21

Congrats for the article. Very well written and really good discussion about it.

Karsten Biedermann • Mar 21

Thank you!

Travis • Mar 20

I’ve always enjoyed a native approach with CSS. I’m please to see more features coming! Great post by the way 🙌

Karsten Biedermann • Mar 20 • Edited

Thank you! It's an interesting time as the features are being rolled out one after another.

D7460N • Mar 22

Going native is awesome.

Karsten Biedermann • Mar 22

yeah!

krakoss • Mar 24

very useful information Thank you very much for this article

João Angelo • Mar 20

Hi Karsten Biedermann,
Your tips are very useful
Thanks for sharing

Karsten Biedermann • Mar 20

I'm very happy to hear that!

Devluc • Mar 20

Totally agree with this, CSS had become flexible enough by itself

Karsten Biedermann • Mar 20

Yes! And it's so much fun to work with native CSS again after a long period when CSS was so frustrating.

peerreynders • Mar 22

I truly believe that in 2024, the benefits of Sass, including installation, usage, and compilation issues, no longer justify its use.

As far as opinions go that's OK. And in some way it states: “The projects that I work on are not complicated enough to warrant using Sass”. That makes sense as well; don't introduce it unless you actually need it, complexity needs to justify its cost.

By the same token one has to be careful because dropping opportunities to exercise a skill ultimately leads to loss of the skill (or worse it's never acquired in the first place) which is detrimental once you find yourself in a situation that could actually benefit from the skill/tool.

Sass largely exists as a organizational aid that is capable of front loading work ahead of runtime.

For example the argument that one doesn't need Sass design time “variables” because CSS runtime custom properties exist is about as non-sensical as claiming JavaScript const is superfluous because let is more powerful due to its mutability.

A Strategy Guide To CSS Custom Properties

Sass as a tool is roughly in the same category as bundlers. Sure there is a “No Build Tool” movement out there but bundlers aren't going anywhere.

It's good to only start using things once you need them
It's also good to be able to immediately recognize when a skill/tool would be useful and start using it for immediate benefit.

The problem occurs when things are added prematurely, “just in case we need to scale” or when nobody recognizes when adding something “right now” will save headaches later.

Vitor Norton • Mar 21

I only used SASS for nesting, nice to know that! Will do only pure css now (just because I don't need sass, but it's a great tool)

peerreynders • Mar 23

Keep in mind that native nesting behaves differently so some adjustments/trade-offs need to be made.

cyrilthomas1983 • Mar 26 • Edited

What about if Developers makes any syntax errors. While using SASS the compiler throws error? What will be the scenario while using pure css

Karsten Biedermann • Mar 26

I use Stylelint in all my Projects to validate the CSS (or SCSS) code: stylelint.io

FrontEndWebDeveloping • Mar 22

Great post! I learned from it.

Karsten Biedermann • Mar 22

Glad to hear!

Adzetko • Mar 25

I admit I'm on point with everything showed here expect for the @container queries. Each time I see an exemple of those I get really confused and my brain just refuses to understand what is happening.

Karsten Biedermann • Mar 26 • Edited

Typically, you specify the container-type in advance in the parent element. For example, if you set @container (width >= 800), it will always check the parent to see how much width is available.

Example:

<div class="parent-container">
  <div class="headline">Test</div>
</div>

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

  .headline {
    font-size: 2rem;
  }

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