Sass vs SCSS vs LESS vs Stylus: Choosing a CSS Preprocessor

Four names, three languages

Sass is one language with two syntaxes. SCSS uses braces and semicolons and lives in .scss files; the older indented syntax uses whitespace and lives in .sass files. Both are compiled by the same program and support exactly the same features, and a project can contain both, with files importing each other freely. The Sass documentation is blunt about which to prefer: SCSS is "with a few small exceptions, a superset of CSS", and "because of its similarity to CSS, it's the easiest syntax to get used to and the most popular". When people say "Sass" today they almost always mean SCSS.

LESS arrived in 2009 and was the first preprocessor most people met, largely because Bootstrap 3 was written in it. It uses @ for variables, treats any ruleset as a potential mixin, and is implemented in JavaScript, which historically meant it could run in the browser as well as in a build step. It is still maintained: 4.9.1 was published on 2 September 2026, and a 5.0 line is in alpha alongside it.

Stylus, from 2010, is the most permissive of the three. Braces, colons and semicolons are all optional, variables are assigned with = and need no sigil, and mixins are ordinary functions that can be called without parentheses. It is also the quietest project of the four: the current release, 0.64.0, was published on 20 October 2024, and it draws roughly 1.5 million npm downloads a week against LESS's 5.6 million and Sass's 15.8 million.

The Sass ecosystem has been through two extinctions whose remains you will meet in older repositories. Ruby Sass, the original implementation, is end-of-life, and LibSass — the C++ port that node-sass wrapped — was deprecated on 26 October 2020 with the recommendation to "use Dart Sass instead". node-sass still draws over half a million downloads a week, a fair measure of how much unmigrated tooling is still running.

The same component in SCSS and indented Sass

Start with the pair that is genuinely the same language. The two blocks below declare two variables, define a mixin that takes an argument, and use nesting with the & parent selector. Everything that differs is punctuation: SCSS closes declarations with semicolons and wraps blocks in braces, and the indented syntax uses a newline and an indent for both. Nothing about the semantics changes, which is why converting between them is mechanical and safe — the job the SCSS and Sass syntax converter does in one pass.

The indented syntax is denser and produces cleaner diffs, since no line contains only a brace. Against that, it is not a superset of CSS: you cannot paste a snippet from documentation, a vendor stylesheet or DevTools straight into a .sass file, which is why most teams pick SCSS. That single trade — density versus paste-compatibility — is the whole argument.

Both syntaxes give you the features that still justify a preprocessor at all. $variables are resolved at compile time; @mixin takes arguments and injects whole declaration blocks; the maths in $gap * 0.5 is done by the compiler, so the browser never sees an expression. Note also that a mixin is not a class: nothing appears in the output unless it is @include-d somewhere.

/* ---------- SCSS (.scss) ---------- */
$brand: #2563eb;
$gap: 12px;

@mixin card($pad) {
  padding: $pad;
  border-radius: $gap * 0.5;
}

.panel {
  @include card($gap * 2);
  color: $brand;
  .title { font-weight: 600; }
  &:hover { color: #1d4ed8; }
}

/* ---------- Sass, indented syntax (.sass) ----------

$brand: #2563eb
$gap: 12px

@mixin card($pad)
  padding: $pad
  border-radius: $gap * 0.5

.panel
  @include card($gap * 2)
  color: $brand
  .title
    font-weight: 600
  &:hover
    color: #1d4ed8

---------------------------------------------------- */

The same component in LESS and Stylus

LESS marks variables with @, which is its one real design wart: the same sigil introduces at-rules, so @media, @import and @brand all start alike, and variable interpolation needs the extra braces of @{name}. Mixins are not a separate construct — any ruleset can be called as one — and a parametric mixin is written as a selector taking arguments. A mixin defined with parentheses is not emitted as a rule of its own, which is how you keep helpers out of the output; the Less documentation notes that the parentheses in a mixin call are now expected, since "optional parentheses are deprecated".

LESS also has guards in place of conditionals, written as a when clause on the mixin — .mixin(@a) when (lightness(@a) >= 50%) — and detached rulesets, which store a whole block in a variable to be called later. Both are genuinely expressive, and both are the parts of a LESS codebase that no converter will translate for you.

Stylus goes furthest in removing punctuation. Assignment is font-size = 14px with no sigil at all; braces, colons and semicolons are optional throughout; and mixins are defined exactly like functions and can be called without parentheses, so card 24px and card(24px) are the same call. The result is extremely terse and, for anyone joining later, extremely ambiguous — a line like margin 0 auto could be a declaration or a mixin call, and only the definitions elsewhere in the file settle it.

/* ---------- LESS (.less) ---------- */
@brand: #2563eb;
@gap: 12px;

.card(@pad) {
  padding: @pad;
  border-radius: @gap * 0.5;
}

.panel {
  .card(@gap * 2);
  color: @brand;
  .title { font-weight: 600; }
  &:hover { color: #1d4ed8; }
}

/* ---------- Stylus (.styl) ----------

brand = #2563eb
gap = 12px

card(pad)
  padding pad
  border-radius gap * 0.5

.panel
  card(gap * 2)
  color brand
  .title
    font-weight 600
  &:hover
    color #1d4ed8

------------------------------------- */

All of them compile to the same CSS

The SCSS, indented-Sass and LESS versions above were each run through their own reference compiler — dart-sass 1.104.0 for the two Sass syntaxes, less.js 4.9.1 for LESS — and all three produce the byte-identical output below. That is the honest summary of the syntax debate: once the file has been compiled, there is no way to tell which dialect it came from. Nesting has been flattened into descendant selectors, & has been replaced by the parent, the variables are gone, and $gap * 0.5 has become 6px.

Two details are worth pointing at. Nesting produces .panel .title, a descendant selector rather than a compound one — every preprocessor works this way, and every over-nested codebase pays for it with selectors five levels deep that nothing can override. And the arithmetic happened once, at build time, so the browser receives a constant: compile-time maths is genuinely something CSS cannot do outside calc().

To see this on your own files, the SCSS to CSS compiler runs dart-sass and the LESS to CSS compiler runs less.js, both in the browser, so the output is what your build would produce. Compiling is also the fastest way to audit an inherited stylesheet: the CSS tells you how many rules a seemingly small mixin is really generating.

.panel {
  padding: 24px;
  border-radius: 6px;
  color: #2563eb;
}
.panel .title {
  font-weight: 600;
}
.panel:hover {
  color: #1d4ed8;
}

Imports and modules: where the dialects really differ

Syntax is cosmetic; module systems are not. Sass replaced its old @import with @use and @forward in 2019, and the difference is real: @use loads a file once no matter how many times it is referenced, and its members arrive under a namespace instead of being dumped into one global scope. The old rule is on its way out — "as of Dart Sass 1.80.0, the @import rule is deprecated and will be removed from the language in Dart Sass 3.0.0" — and an official migrator exists to rewrite a codebase automatically.

The same modernisation applies to Sass's built-in functions, which is the deprecation most teams meet first. Compiling darken($bg, 8%) with dart-sass 1.104.0 now prints two warnings — "Global built-in functions are deprecated and will be removed in Dart Sass 3.0.0" and "darken() is deprecated" — and points at color.adjust or color.scale from the sass:color module instead. Old tutorials are full of the deprecated forms, so a stylesheet copied from a 2018 blog post will compile today and stop compiling at the 3.0 boundary.

LESS keeps everything in one global scope and puts the sophistication in the import options instead: (reference) imports a file for its mixins without emitting its rules, (optional) tolerates a missing file, and (inline) passes a file through untouched. Namespacing is by convention, with mixins grouped under a wrapper selector and called as #library.my-mixin(). Stylus offers @import plus @require, which "works almost in the same way, with the exception of importing any given file only once" — the same idea as @use, without the namespacing.

This is the part of a migration that actually costs time. Translating $ to @ is find-and-replace; turning a codebase that assumed every variable was global into one where each file declares what it uses is a genuine refactor, and no converter can do it for you.

// Modern Sass: namespaced, loaded once, built-ins from a module.
@use "sass:color";
@use "theme" as t;

.button {
  background: t.$brand;
  &:hover { background: color.adjust(t.$brand, $lightness: -8%); }
}

// The deprecated forms you will find in older tutorials:
//   @import "theme";                    // removed in Dart Sass 3.0.0
//   background: darken($brand, 8%);     // use color.adjust / color.scale

/* LESS equivalent — one global scope, richer import options:
     @import (reference) "theme.less";
     .button { background: @brand; &:hover { background: darken(@brand, 8%); } }

   Stylus equivalent — @require imports a file only once:
     @require 'theme'
     .button
       background brand */

What native CSS took back

Most of what preprocessors were adopted for in 2012 is now in the browser. Custom properties give you variables that are better than the compile-time kind, because they cascade, can be redefined per selector or per media query, and can be read and written from JavaScript — which is what makes runtime theming and dark mode straightforward. Nesting is Baseline: it shipped in Firefox 117, Chrome 120 and Safari 17.2, becoming newly available in December 2023 and widely available in June 2026. Cascade layers (@layer) have been in every engine since March 2022, and color-mix() since Firefox 113 in May 2023.

Native nesting is close to the preprocessor version but not identical, and the difference bites BEM codebases immediately. You cannot concatenate a selector onto the parent: MDN is explicit that Sass's .component { &__child-element { … } } pattern "is not possible in CSS nesting", because "when a combinator is not used, the nested selector is treated as a type selector", and writing &Element "makes the CSS selector, and the entire selector block, invalid". If your naming convention depends on building class names out of fragments, that convention is what ties you to a preprocessor, not the nesting itself.

What is left that CSS still cannot do? Mixins with arguments, above all — there is no way to say "paste these six declarations with this value substituted". Loops such as @each and @for, which generate a family of utilities from a list. Functions and maps for design tokens. @extend, for better or worse. And partials, which split a stylesheet across files at no runtime cost. If you need none of those, a preprocessor is now pure build-step overhead, and the CSS formatter plus CSS minifier cover what remains.

/* Runtime variables that cascade — better than compile-time ones */
:root { --brand: #2563eb; --gap: 12px; }
[data-theme="dark"] { --brand: #60a5fa; }

@layer base, components, utilities;   /* explicit cascade order */

@layer components {
  .panel {
    padding: calc(var(--gap) * 2);
    color: var(--brand);

    .title { font-weight: 600; }             /* native nesting */
    &:hover { color: color-mix(in oklab, var(--brand) 85%, black); }
  }
}

/* What still does not work natively: */
/* .panel { &__title { … } }  →  invalid: & cannot be concatenated */

Choosing today, and migrating between dialects

For a new project, start with plain CSS. Custom properties, nesting and @layer cover the common cases, and skipping the build step removes a category of tooling problems. Add SCSS when you hit a real need — utilities generated in a loop, parameterised mixins, tokens held in maps — and add it as a thin layer rather than rewriting everything. There is no good reason to start a new codebase in LESS or Stylus in 2026: both work, but the ecosystem, the documentation and the hiring pool are all with Sass.

For an existing LESS codebase there are two honest destinations. Compiling to plain CSS and maintaining that is right when LESS was only ever providing variables and nesting, which the browser now does; the LESS to CSS compiler does exactly that with less.js. Moving to SCSS is right when you depend on mixins and functions, and the mechanical half — @ to $, .mixin() calls to @include, guards to @if — is what the CSS preprocessor converter handles. It translates syntax rather than evaluating it, so mixin bodies survive the trip and are recompiled at the other end.

Indented Sass to SCSS is the easiest migration of the four, because it is the same language: SCSS and Sass conversion goes both ways and compiles identically. Stylus is the one to plan an exit from, given a release cadence measured in years. In the other direction, plain CSS arriving from a designer or a vendor can be brought into the house dialect with CSS to SCSS, which nests it and pulls repeated values into variables.

Two habits make any of these conversions go better. Format first — a stylesheet with one declaration per line converts far more predictably than one with three rules on a line, so run it through the SCSS formatter or LESS formatter. Then verify by compiling: convert, compile, diff the CSS. If the CSS is unchanged, the migration is correct by definition.