For years, Sass variables were the only way to manage colors systematically in CSS. You defined $primary: #4f46e5; once and referenced it everywhere. Then CSS custom properties (native variables) arrived, and the landscape shifted permanently.
The Critical Difference
Sass variables are compiled away. After the build step, $primary is replaced by #4f46e5 in every location. The variable does not exist at runtime. CSS custom properties are live. var(--primary) is resolved by the browser at runtime. The variable exists in the DOM and can be inspected, overridden, and changed dynamically.
Why This Matters for Color Systems
Runtime resolution means CSS variables support theming (swap a class to change colors), dark mode (override variables under a dark-mode selector), component scoping (override a variable for a specific section), and JavaScript manipulation (change colors dynamically). Sass variables support none of these without recompiling.
Where Sass Still Wins
Sass has functions: darken($color, 10%), lighten(), mix(), adjust-hue(). These manipulate colors at build time. CSS has color-mix() now, but Sass's color functions are still more complete and battle-tested. For generating shade scales at build time, Sass remains useful.
The Modern Best Practice
Use CSS custom properties as your production color tokens (what PaletteRx exports). If you use Sass in your build pipeline, you can generate CSS variable declarations from Sass functions: define shades in Sass, output them as CSS variables, and reference the CSS variables in your components. This gives you Sass's generation power with CSS's runtime flexibility.