Less Mixins vs Variables: Choosing the Right Tool for Design Tokens

When you build a shared style layer in Less, the recurring decision is whether a design token should be a variable (@brand-color) or a mixin (.button-base()). Pick wrong and you either scatter magic values across files or bloat your compiled CSS with duplicated rule blocks. The rule of thumb: variables carry single values, mixins carry groups of properties that must travel together.

The decision and its constraints

A design token is any reusable piece of your visual language: a brand color, a spacing unit, a button's padding-plus-radius-plus-font stack. Less gives you two mechanisms for reuse, and they compile very differently:

• Variables hold one value. At compile time, Less substitutes the value wherever the variable is referenced. The output contains only the final CSS value.
• Mixins hold a block of declarations. At compile time, Less copies the entire declaration block into every call site.

That compilation difference is the whole trade-off: variables cost nothing in output size, while mixins duplicate their body each time they are called.

Comparison at a glance

When variables win

Use a variable whenever the token is a single value that might change globally: brand palette, spacing scale, breakpoints. One edit updates every usage, and the compiled CSS stays lean because only the value is emitted.

// tokens.less
@brand-primary: #2b6cb0;
@space-unit: 8px;
@font-size-base: 16px;

// usage
.card {
  color: @brand-primary;
  padding: @space-unit * 2;
  font-size: @font-size-base;
}

Watch the scoping rule: a variable defined inside a selector is only visible within that selector's scope. Define shared tokens at the top level of an imported file, or consumers won't see them.

When mixins win

Use a mixin when several properties must change together to keep a pattern intact. A button's hover state, flexbox centering, or text truncation are classic cases — the individual properties are meaningless alone.

// patterns.less
.flex-center() {
  display: flex;
  align-items: center;
  justify-content: center;
}

.truncate(@max-width: 100%) {
  max-width: @max-width;
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

// usage
.toolbar {
  .flex-center();
}
.sidebar-title {
  .truncate(240px);
}

Parameterization is the mixin's edge: .truncate(240px) injects a per-call value while keeping the pattern's structure fixed. Variables can't express that.

The bloat trade-off, made concrete

Every mixin call copies the full declaration block into the output. If .flex-center() is called in 40 components, those three flex declarations appear 40 times in the compiled CSS. Variables never do this. For a mixin called heavily across a large app, measure the cost before committing:

# Run in your project root; requires the less package (npm i -g less or npx)
npx lessc styles/main.less out-variables.css
npx lessc styles/main-with-mixins.less out-mixins.css
ls -l out-*.css   # compare byte sizes

Run these from your project root with the Less compiler installed (globally via npm i -g less or on demand via npx). No special permissions needed; the only risk is overwriting the output files, so use throwaway names. If the mixin version adds meaningful kilobytes, consider whether the pattern could be a plain utility class in your HTML instead — one definition, zero duplication.

Validating the result

Two quick checks confirm your token strategy compiles as intended:

1. Inspect the output. Open the compiled CSS and search for a token value (e.g., #2b6cb0). It should appear wherever referenced, with no leftover @ syntax — that would indicate a compile failure.
2. Test parameter passing. Call a parameterized mixin with two different arguments and confirm each call site in the output carries its own value. If both show the default, the argument isn't being passed correctly.

Limitations

This guidance assumes Less 3.x/4.x behavior with the official lessc compiler. Deeply nested mixins (mixins calling mixins several levels down) increase compile time and make debugging painful, since browser dev tools show only the flattened CSS. Keep mixins shallow — one or two levels at most — and prefer variables for anything expressible as a single value.