Material-design-lite: Decide on SASS vs. just PostCSS + plugins

[traviskaufman]

@rfru @sgomes @Garbee

Let's all post our thoughts / pros + cons in comments below and then decide.

[traviskaufman]

Prior PostCSS trial: #3420

So as of now I'm still sold on Sass, but:

• I've used it way more than raw PostCSS
• I could most definitely be convinced otherwise.

Sass Pros:

• Widely recognized and understood by developer community. Seems much more popular than PostCSS / CSSNext.
• @import. We can easily split up our code into logical modules, and it's integrated directly into the language.
• It's "batteries-included". We don't have to spend time setting up, configuring, and updating a bunch of different plugins.
• We can still use whatever PostCSS processing we want after transpiling from sass, but that's not true the other way around.
• We can easily move from sass code to modern CSS as new features become stable in all browsers. However, starting with PostCSS and then deciding we want to move back to sass seems much harder.

Sass cons:

• Non-modular - Either buy into all of SASS or none of it
• Slower (apparently) than PostCSS. That being said, I'd like to see benchmarks on node-sass vs. postcss. Ruby-sass I can totally see but I'd figure that node-sass would be similar in speed to postcss.
• Non-extensible - However, I don't see this being as big of an issue since we can do a postcss pass after transpilation from sass.
• Does not promote future CSS - Devs may be tempted to rely on sass patterns rather than using future CSS equivalents.

As of now my position is still _let's use sass for what it's good for (maps, mixins, importing, reusable styling code) but not at the expense of future-forward css_. So for example instead of _just_ using sass variables for theming, we write a mixin that uses custom properties if supported and if not falls back on the hard-coded sass variable value. If we ever get to a point where we feel sass isn't necessary in the future, we can simply just drop the sass pass and just transpile using postcss.

Also, since we're going to be including the dist'd css on a per-component basis, using the code with other build systems shouldn't be as much of an issue anymore.

[traviskaufman]

That being said, precss looks like it could be a good compromise but I still want to see the value add of that over sass.

[Garbee]

The popularity front is expected, Sass has far more age on it and is used in many more projects because of that.

@import has a module for that which we'd take advantage of to make sharing the global variables easier. That is the only module we'd use that isn't something browsers can do directly down the road.

One con of the "batteries included" part is the power it provides. It provides a bunch of functionality and we'd need to scrutinize components and all PRs making sure the output is what we expect. Otherwise it is easy to fall into over-precise selectors.

If we are using PostCSS at all, I think we should go ahead and use it as our base to provide the most concise output we can. Using Sass to say, using CSS vars or fallback if not supported just creates more bloated output for us. When we could easily pre-compile down before shipping until more browsers support vars and we can just turn it on by default in the output itself.

Overall, if we had a way to easily restrict what gets used in Sass and monitor the output so it wasn't a manual thing, then I'd consider staying with it more than I am now. As it is, we have the _major_ benefits of Sass landing in CSS Standards now, such as Variables and hopefully soon @apply will be on a standards track. Writing plain CSS and transpiling back to support more browsers while the new stuff isn't out yet seems like a much better strategy for maintainability then trying to marry Sass and PostCSS together and create an even more confusing codebase for contributors.

Our JS-side is getting very complicated as it is. CSS has long been a pain for developers in the first place, I'd rather we keep it simple even at the expense of keystrokes (which aren't a big deal) so other contributors can more easily understand it and help out.

[traviskaufman]

One con of the "batteries included" part is the power it provides. It provides a bunch of functionality and we'd need to scrutinize components and all PRs making sure the output is what we expect. Otherwise it is easy to fall into over-precise selectors.

Interesting point, although I feel like having using a linter mitigates a lot of that.

Writing plain CSS and transpiling back to support more browsers while the new stuff isn't out yet seems like a much better strategy for maintainability then trying to marry Sass and PostCSS together and create an even more confusing codebase for contributors.

That's a really great point. I could definitely see the confusion and complexity increasing as our codebase grows.

So I'm def coming around to using PostCSS. However I think if we do use them, we should at least _start_ with packs rather than pick and choose our own plugins from the get-go. The reasons being:

• We don't have to worry about individual plugin ordering
• We can rely on community-test and (hopefully) community-proven combinations
• The pack authors can update packs as specs change, which blocks this churn from us.
• We don't have to worry about version updates between individual plugins and resolving conflicts that may arise due to them (pack authors can do that for us).
• We'll probably wind up bringing in most - if not all - of the plugins in these packs ourselves.

Personally I really like the precss + cssnext combo. We can use stylelint to make sure we're not doing anything that's going to produce bad or bloated styles.

[rfru]

My vote is for limiting to standards-compliant, future-forward CSS where possible. It would be advantageous to position ourselves as a "vanilla" library in as many respects as possible, especially for Polymer's sake.

Given that, I would lean towards PostCSS + cssnext.

[traviskaufman]

Decision

PostCSS + CSSNext + Stylelint

• We'll try and stay as close to standards-compliant, future-forward CSS as possible.
• In the future we can add/remove plugins as needed
• If using a pre-built plugin pack is deemed to be too limiting, we can swap it out for individual plugins in the future.

[lkraav]

Heya. I'm new to the library and got confused: did the move to PostCSS ever... khrm materialize? package.json still says gulp-sass.

[Garbee]

No it didn't. We got through parts of the conversion but realized Sass provides a huge level of maintainability benefits. So we never merged the postcss transition that was done in favor of sticking with Sass + postcss to supplement where necessary.