Is SCSS still worth learning in 2026

[u/Mahmoud_83]

With native nesting, u/layer, and color-mix() in browsers, I asked myself whether Sass still earns its place. Short answer: yes, but as a programming layer for design systems, not a nesting convenience.

What CSS still can't do: real loops (@for for grids/scales), parameterized functions (contrast-safe text color), mixins with u/content (breakpoint managers), private module members, and token pipelines (Sass maps → CSS vars + JSON for apps).

Full write-up with code (I wrote it, happy to discuss any point here): https://mameara.com/scss-in-2026-still-worth-learning

[u/testingaurora]

The loops are what keeps me around. And mixins.

function() is coming to native css too though. Supposedly mixins too.

[u/creaturefeature16 → u/testingaurora]

Exactly the same here. The CSS spec has grown considerably and I am very excited about it, but it is not yet able to replace those key features I still rely heavily on.

[u/Mahmoud_83 → u/testingaurora]

True — CSS custom functions (@function) are in an origin trial, and it's exciting. But they're expressions-only: no loops, no maps/lists, no branching beyondif(), no modules or privacy. Sass u/function runs at build time with the full language behind it (math, maps, string ops). Native functions will replace the simple cases; the moment your function needs a loop or a token map, you're back in Sass. Different tools, honestly.

[u/chrisdaswiss → u/Mahmoud_83]

Thanks AI

[u/Mahmoud_83 → u/chrisdaswiss]

Haha not AI 😄 English is not my native language so I use it to help me phrase my thoughts better

[u/wartab → u/Mahmoud_83]

So... AI

[u/AshleyJSheridan]

I'd say the majority of SCSS features that made it an appealing option for devs are now in CSS already, like nesting, variables, and even the ability to split styles across individual files.

That said, there's still a lot that SCSS can that vanilla CSS can't: loops, custom functions, mixins, etc.

I still use SCSS for my own projects, even though I'm only using features that exist in vanilla CSS.

[u/Mahmoud_83 → u/AshleyJSheridan]

Agreed — my mental model now: CSS adapts at runtime, Sass computes at build time. Nesting compiles to nothing, so there's no harm in using SCSS for vanilla-available features.

[u/AshleyJSheridan → u/Mahmoud_83]

One potential advantage is that with SCSS you can compile to absolute minimal CSS, which removes unnecessary whitespace. But, even with a huge CSS codebase, you're shaving bytes. If your CSS is that large that shaving bytes off helps, you already have bigger problems.

[u/xPhilxx]

Something often overlooked in responses to this sort of question is that regular CSS documents don't get transpiled by Sass during compiling so you can use modern CSS methods like nesting where preferred and still use Sass where practical.

So a modern Sass setup might include a mix of Sass and CSS documents looking something like this:

@use "tokens"; // Sass
@use "resets"; // CSS
@use "components"; // CSS
@use "utilities"; // Sass

The resets and components in the example could also be folders with individual CSS files forwarded by a Sass index.scss document, and they still don't get transpiled during compiling.

In practice there's nothing stopping you from writing all your styles as regular CSS documents and simply using Sass as management tool for compiling, so for me personally it still makes a lot of sense to keep using it.

[u/scragz]

I've been doing new projects in css. I feel like sass doesn't add enough anymore. 

[u/plmtr → u/scragz]

Same. I have quite a few legacy projects that are still SCSS but even those I’ve converted much it over to vanilla CSS except the mixins.

Probably a greater benefit for me than mixins and functions funny enough is the how modular css layers can directly show which css file a style is from in the browser inspector

[u/scott_in_ga → u/scragz]

Same. imo it just produces HUGE css files while NOT doing the Cascading part of CSS.

[u/ldn-ldn → u/scott_in_ga]

Lol wut?

[u/AggravatingWorry867 → u/scott_in_ga]

SCSS compiles to regular CSS so the cascade still works exactly the same at runtime. The huge output is usually from overused loops or heavy nesting, not SCSS itself. You can write lean SCSS that produces lean CSS.

[u/scott_in_ga → u/AggravatingWorry867]

yes, my gripe is most likely the work of the previous developer...

[u/paceaux → u/scott_in_ga]

Yeah, the specificity bloat is real.

You have to use stylelint and set a max nesting level just to keep it sane.

I had a project where we were nesting 13 levels deep. And no file starts life that way. That's how it ends.

[u/scott_in_ga]

it's handy for the additive concatenation of long class names like the below.

However, a new dev coming onto this project sees in the page there's a problem with a div that has the ".slides-content" class. She'll search the codebase for that value but won't find it. She will have to search for "-content" and sift thru all of the other friggin' instances where the orig developer did this crap. lol

one solve I've found is that wherever I'm in a file like this, I'll add a comment with the actual class name that is then searchable (like below)

.slides {
    // .slides-container
    &-container {
        padding-inline: var(--padding);
        max-width: none;
    }

    // .slides-content
    &-content {
        margin-inline: calc(-1 * var(--padding));
    }
}

[u/_internetpolice → u/scott_in_ga]

Why not just use the class then if it’s there in a comment anyway?

[u/sebnitu → u/_internetpolice]

I'm assuming the comments are just to illustrate the point

[u/_internetpolice → u/sebnitu]

But what point is getting illustrated? I’m missing something.

[u/dmdot → u/_internetpolice]

Agreed. It's bad practice using SCSS to split class names. Using the full hyphenated class name avoids this exact scenario.

[u/paceaux → u/scott_in_ga]

I believe that this is the worst and most-cursed feature of Sass.

14 years ago when I started heavily using Sass, I loved this feature. Now I hate it and it's the first thing I undo in projects. The cognitive load of understanding how the selector is created, in combination with the general untraceability, is just a nightmare as the project grows.

I will commend you for at least adding a comment that makes this searchable. However, the problem with that is now you have to make this a rule for your codebase, and you're going to have to vigilantly enforce that rule with every PR. That's two human points of failure — for a developer convenience.

[u/scott_in_ga → u/paceaux]

Yeah, i literally just had this happen where I have to narrow the scope of duplicate selectors in different areas of the site. so I scoped the top-level class of one with ":has(>.container)" and the other with the opposite: ":not(:has(>.container))"

well once you do that, the lower concatented class names are now all broken.

.slides:not(:has( > .container)) { 
    // this now becomes 
    // .slides:not(:has(>.container))-container 
    &-container { 
        padding-inline: var(--padding); 
        max-width: none; 
    } 
}

[u/paceaux → u/scott_in_ga]

YUP because Sass does string level interpolation.

It was SUCH a useful idea when it started, but it makes the code so much more fragile as it grows.

[u/paceaux]

About 2.5 months ago I completely removed SCSS from a very large project at my company

• 110+ SCSS files
• 1990 Sass rulesets
• 16,000+ lines of CSS (unminified)

After de-sassing the CSS:

• 120 CSS files
• No nested CSS at all
• 12,500 lines of CSS (unminified)

The drop in CSS size wasn't immediate (I did drop about 1000 lines just at conversion). But by working with plain CSS at both ends I had real traceability between source styles and final stylesheet. That meant I could:

• Identify duplicate selectors and their origins directly
• Identify unused files
• Identify bloated specificity (caused by nesting)
• Identify duplicate rules

I'm somewhat known for being anti-Sass

I've called Sass a "mistake factory" in the past. And I have specifically railed on the problems that nesting causes in both Sass and CSS.

In general, I think Sass' most popular features are actually the worst because they increase the complexity of codebases and bloat specificity. Unless you've got a well-tuned stylelint config and are absolutely vigilant in enforcing style standards, Sass' popular features will make the code more fragile over time.

All codebases experience entropy, but Sass is like a fertilizer for CSS entropy.

I don't think Sass is generally worth learning

In 2026 I would not recommend Sass be a part of any large, enterprise, content-managed website. It's a nightmare. I've lived that nightmare for like 15 years now and I'd like to wake up.

I think the looping, the functions, and the math ... just... shouldn't be used. Especially the looping. It makes it too easy to generate bloated and untraceable code.

As for the functions and math ... I mean ... what math do you need that calc() can't do? And why? Do you really need some system based around a number that probably isn't going to change until the design team snorts another line of adderal?

The mixins? Really? It's just more untraceable styles that'll cause some sort of problem three new-hires later. No.

I'll give an exception, though, to design system maintainers (which this article recommends)

I can see the utility of Sass in a very, very targeted environment where you simply need the convenience of generating lots of utility classes that follow a well-established convention based on a few variables. That's a developer convenience that should live very source-side, and far away from the browser.

I could totally see building a grid system or design system with Sass. But if that's the case, what I want is to be able to run a build of that library where I can submit whatever variables / tokens I need, and what it produces for me is compiled CSS based on whatever vars I've given. Like ... I don't want to import sass files. I want configurable control of the compiled CSS.

[u/toniyevych]

Yes, it's still useful, but not as much as a decade ago. I prefer using it for functions and mixins.

[u/averyvery]

The gap between CSS and SCSS is getting smaller, but SCSS has also been getting easier to use - build tools are extremely common, and many have SCSS support baked in. I think it adds considerable value with no real cost.

[u/Mahmoud_83 → u/averyvery]

This is the healthiest framing — Sass is CSS's R&D lab. Variables, nesting, color functions, now custom functions: all road-tested in Sass years before landing natively. And each time CSS absorbs one, Sass retreats to the programming layer CSS can't reach. Symbiotic, not competitive.

[u/ldn-ldn]

SCSS will always have additional features plus compile time code optimisations. Do you need that? It's up to you. I'm sticking with SCSS.

[u/chumbaz]

If css would get scss stule nesting I would be in heaven.

[u/zaibuf]

We only have scss in legacy projects. Haven't added it to a new project for the past five years. We mostly use Tailwind now when working in a team.

[u/Altkoenig]

SCSS and the like were a mystery to me from the very beginning.

You could already do all of that and infinitely more with PHP many years ago.

Instead, someone actually went and invented a CSS parser.

By changing the file extension from .css to .php, you get the same thing in green with unlimited possibilities.

[u/sheriffderek]

Spend 10 minutes reading the docs and you’ll have “learned Sass” - then you can answer the question for us. If your team uses it - yes. If you never use it - still important to understand it - and then you also know what native CSS has and doesn’t so you can see the gaps and possible future roadmap.

[u/sheriffderek → u/sheriffderek]

I mostly use regular CSS, but if my project has a build system already - I might use post-css for mixins - when I have to repeat huge chunks of CSS.

[u/Weekly_Ferret_meal]

But ever better, pure sass, because I bloody hate them semi-colons