Change the pre-processor for css

[trusktr]

Currently, we are using stylus for writing CSS but we can consider moving with LESS or SASS (preferable).

[trusktr]

Why is Less or Sass marked as "preferable"?

---

I vote for PostCSS, to stay in line with future CSS specs. See also CSSNext which is basically a preset that configures a collection of PostCSS plugins out of the box.

---

Although the Sass SCSS syntax is nice, I dislike the tooling very much because it relies on native builds for each platform (written in C++). Any time that someone runs npm install node-sass, it will run a node-gyp build to build the native modules.

I have used Sass a ton in various projects, and lately I have been so annoyed with build errors and things not working due to native modules getting in the way, that I've personally been happier using pure-JS alternatives like Stylus.

Even if Sass syntax is nicer, the Stylus tooling is much more friendly. I haven't ran into any problems with Stylus tooling, but with Sass I swear every other week some build problems happen and it gets very annoying to have to stop developing to figure out what's wrong. And even rm -rf node_modules && npm install doesn't even fix the issues sometimes, which is incredibly a pain in the bum.

In my humble opinion, choosing Sass will introduce a maintenance burden, and some end users may even open new issues when they encounter these problems although it isn't our fault.

Let's no pick Sass!

---

I haven't used Less for a long time, I'm not familiar with its tooling lately, but it is written in pure-JS, which I am totally in favor of over Sass's C++, regardless of how good Sass's syntax is.

[trusktr]

Here's an interesting stat. Weekly download for each:

• Stylus, 1.7m
• Sass, 1.8m
• Less, 2.5m
• PostCSS............ 24.4m!

[anikethsaha]

I am always ready to bet on postCSS. it gives us a huge control to our processing.

let's have postcss then.
I am thinking of having plugins packs in order to keep it consistent.

We need to list down some plugins which we want to use .

currently I am thinking of

• postcss-preset-env or CSSNext ?
• autoprefixer
• cssnano - we are using this currently.

any other ?

[anikethsaha]

I will take a dig in this soon. will create a pack with the plugins we want.

[trusktr]

I forgot CSSNext was deprecated in favor of postcss-preset-env, which is looking nice.

Regarding plugins, do you want to avoid just choosing, for example, all stage 1+ features of preset-env. In particular I like the CSS Nesting module, which is currently a stage 1 proposal.

(Neat that all these features are proposals for actual CSS, so eventually we may remove build steps for them, unlike Sass/Less/Stylus!)

[anikethsaha]

Regarding plugins, do you want to avoid just choosing, for example, all stage 1+ features of preset-env. In particular I like the CSS Nesting module, which is currently a stage 1 proposal.

nesting is one of the things I am interested to write for future CSS. I wonder if we can pick the features and use them.?

[anikethsaha]

I think we can . ref this

[trusktr]

I wonder if we can pick the features and use them.?

It may be easier to just pick "stage 1", but yeah we can also just pick individual features. It's only for dev mode anyways, so it may not matter if there's more dependencies or not for compiling the CSS.

[trusktr]

Also nice list of features by stage at http://preset-env.cssdb.org/features, and http://cssdb.org has the official list of proposals with stage level.

[anikethsaha]

cool, lets have stage 1 then

[jhildenbiddle]

I think discussions like this are most productive when we focus on problems that need to be solved. Perhaps I'm missing something, but so far I haven't read an "issue" in this issue.

That being said, I do have some thoughts on the pre/post-processor debate that may be useful for future discussions. As the author of a complex grid system compatible with Less, Sass, Stylus and PostCSS, I've spent my fair share of time with each of these tools.

• PostCSS is not an either/or discussion. Many projects (including docsify-themeable) use both a pre-process like Sass and PostCSS. There are scenarios where PostCSS is the only processor capable of accomplishing a goal, and IMHO this is where its true value lies (not just as a replacement for Sass/Stylus/Less).

• PostCSS is not a 1:1 replacement for pre-processors like Less, Sass, and Stylus. Plugins provide functionality similar Less, Sass, and Stylus but it's up to you to cobble together a working system. Yes, it's flexible, but that flexibility comes at a cost: the syntax and features available will be unfamiliar to developers unless they are familiar with a project's PostCSS configuration, documentation is scattered across plugin repos, plugin quality is varied, plugins can break with new versions of PostCSS, plugin order must be configured properly, etc. These are all things to consider when maintaining an OSS project with developers of varying skill levels. It's faster and easier to send devs to the Sass/Stylus docs than it is to ask them wrap their heads around a custom PostCSS configuration, and it's easier to manage a single dependency for Less/Sass/Stylus that it is to manage all of the plugins required for a feature-rich PostCSS configuration that aims to replace Less/Sass/Stylus.

• Download metrics are not a useful measurement of value. PostCSS, by itself, doesn't actually do anything (the plugins do). Those 25.9m downloads/week give no indication as to how PostCSS is being used, so it would be misguided to assume devs are choosing PostCSS instead of Less, Sass, or Stylus. A better indication would be review the most popular PostCSS plugins to determine the most common use cases. Interestingly, the most popular plugins are those that perform tasks outside the scope of Less, Sass, and Stylus, which indicates that for most projects PostCSS serves a different purpose than Less, Sass, or Stylus.

• Despite the above point, it's worth pointing out that the download stats listed above for Sass are inaccurate. There are two popular implementations of Sass that run under Node: sass (1.98m/wk) and node-sass (5.2m/wk). Combined, these make for over 7m downloads/week. If download stats are of any importance, then Sass has a clear lead over Less and Stylus.

• Less, IMHO, is not an option worth considering. Basic pre-processor functions like loops require a hacky syntax and extending its functionality with plugins is an exercise in frustration due to the lack of proper documentation.

• Sass and Style are very similar in terms of functionality, with each having a few features the other lacks. For 99% of devs, the decision will come down to syntax preference, not feature requirements.

• Dart Sass is the newest version of Sass. It compiles to pure JavaScript and addresses the concerns mentioned above (those issues are associated with node-sass).

Whew.

My vote would be for PostCSS + (Dart) Sass largely because this is what docsify-themeable currently uses. I could make the conversion to something else, but I don't see how that would be a good use of time without some compelling arguments.