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
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.)
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
@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.
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?