When to stop using SCSS (native CSS catching up)

Think of this as the honest one: native CSS has caught up with much of what sent people to Sass in the first place. SCSS still earns its place on some projects. On others it is overhead. Knowing the difference saves you maintaining a compiler nobody needs.

What native CSS does now

• Custom properties – runtime theming without a preprocessor
• Nesting – supported in modern browsers (and via PostCSS where not)
• @layer – cascade control Sass never solved cleanly
• color-mix(), light-dark() – colour logic in plain CSS
• Container queries, :has() – layout and selector power Sass only ever forwarded

/* Native nesting - no Sass required */
.card {
  padding: var(--space-md);

  &__title {
    font-size: 1.25rem;
  }

  &:hover {
    box-shadow: 0 2px 8px rgb(0 0 0 / 0.1);
  }
}

:root {
  --color-primary: #0066cc;
  --space-md: 1rem;
}

What SCSS still does better

• Compile-time token maps and loops – generating brand CSS files from data
• Complex mixins with logic – breakpoint helpers, typographic scales with guards
• Large partial trees with @use – module boundaries at author time
• Math and colour functions at build time – when you need calculated values before deploy

If your SCSS mostly holds variables and nesting, you may be paying for a compiler to do what CSS already handles. If your SCSS generates four brand bundles from shared maps, the compiler is doing real work.

Decision signals

Stay on SCSS when:

• Multiple compile-time themes or white-label builds share one source tree
• Maps and loops generate utilities or component variants you would otherwise maintain by hand
• Your team already ships SCSS packages consumers depend on
• Legacy codebase size makes a big-bang migration unrealistic

Consider plain CSS when:

• New greenfield project with modest styling needs
• Tokens live in custom properties and swap at runtime
• Build pipeline complexity outweighs author-time convenience
• Framework or CMS expects plain CSS files with no compile step

Hybrid is normal

Many teams keep SCSS for tokens and component authoring, compile to CSS, and treat the output as the public API. New features get written in native CSS inside .css files that sit beside SCSS partials. Over time SCSS shrinks without a rewrite weekend.

// tokens.scss - still Sass: maps, loops, brand builds
@use 'brand-maps';

// new-feature.css - plain CSS with nesting, no compile beyond PostCSS
@import 'tokens.css'; /* compiled output consumed as CSS */

There is no prize for using or avoiding SCSS. There is a cost to the wrong choice – either maintaining a tool chain you do not need, or hand-copying values a map would generate once.

Browser support reality check

Check your analytics and Browserslist before dropping Sass because ‘CSS can nest now’. If you still support older embedded browsers, PostCSS nesting or Sass may remain the safer author experience. Match the toolchain to your support matrix, not blog posts.

Try it

• Audit one SCSS file: list what requires Sass vs what could be plain CSS today.
• Rewrite one nested component in native CSS and compare readability.
• Write three sentences on whether your current project still needs a compiler – be specific.