I'm Excited About PostCSS But I'm Scared to Leave Sass

I intend this to be a brief, spontaneous entry about one of my many tooling uncertainties. I hope it will provoke some others to weigh in on a choice that I consider important (if you write stylesheet code) but difficult (unless by haruspicy or other means you know the future) and definitely underdiscussed.

To be mentioned:

• PostCSS — but everywhere I say “PostCSS” you could also think about Rework
• Sass — but everywhere I say “Sass” you could substitute Less

Please follow up with your own tweets or blog posts about “Why we should all switch to PostCSS” or “Why it would be foolhardy not to rely on the Venerable Sass”, etc. (I’m serious. Tell me what to do.)

Standard Syntax and The Future CSS

There are (at least) two essential features that everybody wants (or should want) to add to their stylesheets: variables and calculations. So every CSS processor must provide (at least) those. Sass has its own $variables and operations; Less has its own @variables and operations; but a set of PostCSS plugins offer the synax of custom-properties and calc() — the syntax of present and future CSS standards.

The deeper, wiser parts of me don’t care whether I type $llama, @llama, or var(--llama) as I work. But one thing they do care about (besides the acquisition of desserts) is the interoperability of my syntax, and the only way to achieve that is to establish some kind of standard … which, it turns out, is what standards bodies are for. Because PostCSS plugins enable me to use standard CSS syntax, it’s not out of the question that the code I write using PostCSS might make sense to other CSS processors — not to mention real browsers. Even now, I could switch between postcss-custom-properties and rework-vars, postcss-calc and rework-calc without having to modify my stylesheets. The same should go for all the other PostCSS and Rework plugins that mimic standard syntax. That is fantastic —— that alone is almost enough to convert me.

Sass is definitely “the most mature, stable, and powerful professional grade CSS extension language in the world” (as its website boasts). Like jQuery, Sass is one of the few frontend tools that we can confidently predict will remain popular for years to come. But does that make it more secure and reliable than using standard CSS syntax and PostCSS? Even if PostCSS never takes off or fizzles out (which is unlikely, because of Autoprefixer’s popularity), some other tool could step in and carry the torch, simply by allowing us to use the standardized syntax that browsers will eventually understand.

(See cssnext if you’re interested in PostCSS plugins that “allow you to use tomorrow’s CSS syntax today.” It is packaged as a standalone tool, but all of its pieces are modular.)

Mature and Monolithic or Fresh and Modular?

While Sass delivers a monolithic extension language with a fixed feature-set, PostCSS is a framework with which to build focused plugins. A PostCSS user can selectively include plugins for features that fit her needs, preferences, and whims, or write her own if nothing exists.

Why does this appeal to me?

Sass provides more than I want. Not just more than I want to use; but more than I want myself or the other people working on the same stylesheets to be able to use. I think it offers too much — more than enough to become cleverly counterproductive. (Which specific parts of Sass I’d leave out is a topic for another post.) But I cannot pick and choose pieces of Sass; so if I include Sass at all, I must welcome into my work-home an API that is larger and more complex than I need or want. Through internal conventions and code review, I might be able to enforce a whitelist of Sass features; but I would prefer to be more selective upfront, by limiting what’s possible to what (I think) would be most productive.

(Is there a life lesson in the paragraph above? I’m not sure …)

Also, with compact modules the barrier to creation is low. I am confident that I could contribute to whatever existing plugins I choose to use, and also confident that I could write my own plugins as needed. (Nicolas Gallagher published a good post about doing that with Rework.)

It’s tempting to relate this discussion to ongoing debates about modularity in the JavaScript community, which pit the ideals of small, focused, UNIX-y packages against feature-rich behemoths like jQuery and Ember. In many respects, I think, the analogy makes sense. But if you read through the code of some PostCSS modules (probably short, relatively straightforward code), you’ll see that the simplicity of CSS — both the language itself and the things that we do with the language — seriously alters the premises of comparison, in favor of modularity. Because some of the strongest arguments in favor of large projects like jQuery and Ember hinge on the premise that those projects do things you could never do on your own, solve problems you could never solve on your own, tackle all kinds of complexity that would overwhelm you on your own, etc.; but your CSS problems aren’t really that complex, and with PostCSS you probably have more than enough power to solve them.

A Word About Using Both

You could use both: write SCSS files, compiled them to CSS, post-process those with PostCSS — go hog wild. That’s one way to aggregate power in this world. And if your primary reason for adding PostCSS to your Sass-based process is to have more power at your disposal, that would work. Harness them both. (Use @for and @if and Sass maps and then write crazy PostCSS plugins and make your fantasies reality.)

However: This would not simplify your dev stack — which is one of my goals in considering the switch. This would not selectively limit your powers — another of my goals. And you would still have to choose which process gets to take care of the key features — variables, calculations, imports.

Conclusion?

How do I conclude this?

The more that I write, the more I feel like I should switch from Sass to PostCSS. I seem to be convincing myself — am I convincing anybody else?

But I can’t shake the concern that dropping a tool as proven and popular as Sass — one of the few frontend tools we can truly, indefinitely rely on — is like setting myself adrift, and maybe unnecessarily.

… I should probably write a poem about it.

What do you think?