After having used SCSS/SASS for about five years, I recently quit. It's a great tool, but other tools with the possibility to use only what you need have taken over. And CSS has changed as well.
When I started using SCSS, it was for browser prefix mixins, I had some heavy stuff going on just for supporting flexbox. And even then a lot of the parameters had to be duplicated because the values needed to be different:
// mixins
@mixin flex($values) {
-webkit-box-flex: $values;
-moz-box-flex: $values;
-webkit-flex: $values;
-ms-flex: $values;
flex: $values;
}
@mixin justify-content($value) {
-webkit-justify-content: $value;
justify-content: $value;
}
@mixin justify-contentold($value) {
-moz-box-pack: $value;
-ms-flex-pack: $value;
}
// example
footer {
@include flex(1 3 14rem);
@include justify-content(space-around);
@include justify-contentold(distribute);
}This is only about a quarter of what was my standard mixin stylesheet. Which meant a lot of overhead in both source and bundle. About twenty lines of code for producing what I today can do in two. I also used variables, but mostly for colours and shadows. And nesting and minifying. That's it. I don't like making the CSS setup too smart. I just wanted to write good CSS at a time when CSS needed some help with that.
PostCSS became a way out of SCSS. I configured it to work much the same in order to have a transition period. Changing mixins to autoprefixing was the selling point, I removed a lot of code. And I continued with nesting and variables.
After a while, I started using CSS custom properties as variables. And I stopped using nesting, I don't really need it that much and I found that I wrote more selectors with higher specificity because of it. I do some autoprefixing, but it's not that much of an issue anymore since new features don't use prefixes anymore. Which doesn't mean you don't have to deal with them if you're supporting non-modern browsers. For some projects, I have the prefixed code directly in the original spreadsheet. I don't run 1000 lines of code through an autoprefixer when I know I only need four of them prefixed. Sometimes progressive enhancement or a fallback is enough. And things don't need to look the same in every browser. I don't have to support IE10 and Firefox and Chrome from three years ago and older. But I might fix bugs if they are reported and easily fixable, that's it.
The so-called post-processors gets me closer to writing the CSS I want to write because they're configurable to any level. I want to write CSS that is as close to the finished CSS as possible because that's what the browser reads, handles and shows. The closer I can stay to CSS, the more I know the details of it and the less of supporting features are needed. And I end up with neater code and smaller files.