I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effe

I have to really disagree about extend. Yes, it's easy and potentially disastrous to misuse extend erratically, but used sanely there should never be side effects and your compiled css should be smaller than otherwise. Regarding side effects, they're easy to avoid if you structure your main file in a logical way. For generic extension, your library of base classes (both actual classes and silent classes) should be included before your components which extend and build on them, therefore any inherited styles come before (and can therefore be overwritten by) the extending component but never the other way around. When extending a component, the extending objects should always be in the same file and come after (e.g. .gallery followed by .gallery-foo and .gallery-bar which both extend .gallery). If full blown objects/components are related enough to extend, they're related enough to be in the same file. Avoiding extend compiled file size bloat mostly comes from sane nesting behavior that you should be following regardless. Adding single selectors to an extended rule is almost always going to be smaller than inlining/mixing that rule, even for simple rules. Discoverability is always going to take a hit with extend, yes, but in my opinion dryness, single-point-of-change, and compile size are far more important than in-file discoverability, assuming your project layout is sane. Extend in sass isn't really any different than using traits in oop languages, it's an incredibly useful pattern when employed correctly.