Mixins vs. Functions: Which to Use for Reusable Style Logic in Stylus?

Question

Goal
Determine the most suitable approach—mixins or functions—for encapsulating reusable style logic in Stylus projects, balancing maintainability, CSS output size, and build performance.
Context
Stylus offers mixins that can inject blocks of CSS, and functions that return values for property calculations. Mixins allow positional and keyword arguments, enabling flexible composition, but their expansion can increase compiled CSS size and obscure source origins. Functions are pure, enabling memoization and potentially faster compile times, yet they cannot directly set multiple properties.
Uncertainty
When a style rule needs to be reused across many selectors, developers face a trade‑off: using a mixin may reduce code duplication but risk CSS bloat, while a function may keep CSS lean but requires additional property declarations. The impact on build time and source‑map clarity is also unclear.
Questions

Which approach—mixins or functions—produces the smallest compiled CSS when the same style block is applied to dozens of selectors?
How does function memoization affect Stylus build times compared to the compile‑time evaluation of mixins?
Can mixins be effectively scoped to limit CSS output growth while preserving readable source maps?

Muntasir · Answer

Answer
When the same set of CSS properties is needed on dozens of selectors, a mixin will usually produce the largest compiled CSS because Stylus expands the mixin body at every call site. A function can’t emit a block of properties, so it can’t replace a mixin for that use‑case. The most CSS‑efficient pattern is to move the shared declaration into a reusable class or to use a mixin only for very small, single‑property helpers.
Why Mixins Tend to Bloat

Mixins are inlined: each .foo() call emits the full block of rules in the output file.
With 50 selectors, a 5‑property mixin creates 250 property declarations.
Source maps still point to the original mixin definition, but the output grows linearly with call count.

Functions Keep CSS Lean

A function returns a single value; you still write color: myColor() for each selector.
Only the value is computed once per call, but the property itself is still emitted separately.
Memoization is possible for expensive calculations, but it only speeds compile time, not the CSS size.

Practical Recommendation

Identify the block size: If the block contains more than one property, prefer a reusable class or a mixin only when the block is small.
Use mixins for helper logic: For single‑property helpers (e.g., margin: toRem(16)), a function is clean and keeps CSS output minimal.
Scope mixins with !global or !local: If you must use a mixin, declare it locally to avoid leaking into unrelated selectors.
Measure build time: Compile a test file with 50 selectors using a mixin versus a shared class; compare stylus --out css/ times. In most projects, the difference is <10 ms.
Check source maps: Verify that the generated .map file still points to the mixin definition for debugging clarity.

When to Ask for More Details
If you’re unsure whether the block contains multiple properties or how many selectors will use it, please share:

The exact number of selectors that will call the mixin.
The property count inside the mixin.

These details will help refine the recommendation for your specific build.

Mixins vs. Functions: Which to Use for Reusable Style Logic in Stylus?

Goal

Context

Uncertainty

Questions

1 answer

Answer

Why Mixins Tend to Bloat

Functions Keep CSS Lean

Practical Recommendation

When to Ask for More Details

Your perspective belongs here.

0 question comments