Why I’m Not Breaking Up with Sass

You may have seen a post about “Breaking up with Sass” recently. In it, Ben explains how he chooses not to use several Sass features and is able to replicate the features he does use with a tool called PostCSS. With PostCSS (and a handful of functions & json files), Ben came up with “build your own plugins” system to emulate the Sass features he used. It’s a fascinating idea and Ben’s article is pretty even-handed: he blames himself for the break-up, not Sass. He’s not trying to start a war of words, and I’m not trying to manufacture one. I do want to take some time to share the reasons I’m not breaking up with Sass.

Startup Investment #

PostCSS looks like a great tool. It’s a tool that builds on a lot of other tools, though. If you’d like to use PostCSS, you’ll be installing the whole Node / npm thing and installing and configuring a task runner. Sass, on the other hand, is portable enough to plug in to any workflow. Grunt, Gulp, npm tools, Ruby, etc? Yep, there’s probably a Sass wrapper ready and waiting without requiring you to spend the better part of a day installing, learning, and configuring a new tool. Of course, if you’re already using npm, adding a module like PostCSS probably won’t be too much trouble for you. I’m projecting a bit of my own experience (used Sass for at least a year before using any npm/task-runners). I’m also expressing concern for brand-new users. I started using Sass hesitantly; it was the first real workflow automator I picked up. If the instructions had been more complicated than gem install sass and sass --watch main.scss:main.css, I’d have been intimidated. Sass had all the tools I needed to get started without being overwhelmed by heavy config/setup work.

Features #

Some people don’t use all of the features available in Sass. That’s completely fine. I don’t use every feature in most projects. But all those features are still there. That makes Sass incredible tool to learning. A newcomer to Sass can start of with nothing more than variables, then break up styles into partials, then create mixins for various design patterns, then use a map to manage all the breakpoint data. This gradual onboarding ease in Sass is fantastic, but it’s simply not there with a “build your own plugins” system like the npm+PostCSS+etc system Ben built.

Stability #

Running your own homemade processor is great if you work alone or on small cutting-edge products. (So is Sass!) But if you’re in an agency or on an in-house dev team, you need something everyone can work together on. Most of us don’t want to invent a new system and then spend most our time, mental energy, and emotional capacity troubleshooting it and responding to other people’s bug reports or complaints. On an enterprise level, a stable tool like Sass makes sense.

Community #

This is the biggest reason I’m not breaking up with Sass is that it’s more than just a development tool: it’s a community. I’m not just talking about the fact that Sass is popular enough that it has specific channels in several tutorial/blog sites. I’m talking about people who care about other people. We have At the time of publication, Sass had a conference, a camp, a summit, and meetups around the globe (Austin, Portland, NYC, Charlotte, Denver, London, DC, SF, South Florida, etc). You’ll find Sass talks and workshops cropping up at most front-end or CSS conferences. Why does Sass get so much attention? I’m convinced it’s because of the community: people who love Sass and love teaching others. We’re not perfect, but we care about each other and we want to help newcomers turn into experienced Sass developers. I haven’t found very many other dev communities this welcoming on such a large scale. Honestly, it’s a privilege to be part of it.

Disclaimer #

Once upon a time, Sass was the cool new thing to try and CSS “purists” have been resisting it for years now. I started using Sass after it became widely used, so I can’t personally appreciate what Hampton, Natalie, and Chris went through as pioneers in the early days. I’m certainly not trying to put down PostCSS or any similarly new front-end tool. There’s definitely good reason to push boundaries and try experimental workflows and write new tools. I’m impressed by the people who have the skills to imagine and code those tools.

I’m not breaking up with Sass, and you don’t need to either.