Writing Sass Today

As much as front-end developers have fallen in love with PostCSS, the truth remains that people are still writing Sass at their day jobs. Sass is still really popular and for good reason. Sass is widely adoptable by most platforms, it’s easy to get started with and a really enjoyable syntax.

But all of those things can be a hindrance. A lower barrier to entry can lead to a lack of structure and organization. Personally, out of all the Sass codebases I’ve stepped into, not one of them was adhered to a structure or any guidelines.



Don’t. No good can come from nesting, resist this temptation. Yes nesting empowers that author to group related CSS and bubble out the parent selector. My issue with nesting sits with the person who has to read that code later who didn’t author it. It can really quickly turn into a tangled mess. If you insist on using nesting (again it does have benefits but I don’t feel they’re worth it), move all the base declarations for parent into a single & and then add an extra space between each nested child declaration.



In my opinion, using the @extend method is a bad idea, the output is less than ideal because it creates a lengthy selector parse. I do not recommend it. It’s probably better to move those declarations you want extended into a base class you apply as a utility. The native @apply method seems like a better option to accomplish an that type of extend. Browser support is negligible but the PostCSS toolchain is really helpful for transpiling things like this, there’s a plugin that’s experimenting with the specification.



Mixins are cool. They’re helpful. Supposedly they’re better for performance as they’re not chaining selectors to each other. My opinion of mixins is they’re useful for grouping values together that need to printed out with slight variation. It’s better to try to avoiding to hide magic them. Use them to print out values for certain properties.

Dropbox’s Scooter, takes an interesting approach to using mixins in their project. They use default variables to define a naming prefix to a class plus any default values for that class. I’m assuming this is so those base values can be overwritten and these mixins reused later. But the default values outside the mixin are interesting, this ensures that when the mixin is called even if there’s no values passed into it, it doesn’t return an error.

Never use mixins to output vendor prefixes. There are better tools for this like Autoprefixer.


Functions & Directives