Sass is the CSS extension language of our choice for the additional constructs it offers when creating modularized and DRY styles for components in a Design System.
Key feature for us would be the support for nested declarations. Being able to write composable styles in a concise manner enables the creation of maintainable Design Systems, even if the number of components begins to scale up. In combination with BEM as a convention, it automatically forces developers to think in well defined, maintainable structures when creating additional components. Having to name things, in our mind, is a positive (wink Tailwind), especially when working on long-term codebases that often times have to signal intent to consumers (users and developers of the Design System). Communicating intent with semantic markup and structured, well-named classes is a big part of that.
Especially being able to generate CSS3 in the end, while allowing users to choose between just overwriting some values by defining design tokens / component tokens (staying well within the world of standard CSS3) or utilizing all the mixins, functions and utilities we expose for reuse of shared styling and behavior, when using Sass yourself.
Sass variables are not a huge factor for us, as we're writing design tokens and components tokens directly with CSS Properties. We generate some Sass "theme"-files based on those properties for developers working with Sass and wanting to re-use those already defined values!
