Vue CLI CSS pre-processor option: dart-sass VS node-sass?

Question

Update 09/17/2020:

As this answer gets up-votes every day, I thought maybe it is worth diving deeper into this topic.

---

Considering sass-lang website:

Dart Sass is the primary implementation of Sass, which means it gets new features before any other implementation. It's fast, easy to install, and it compiles to pure JavaScript which makes it easy to integrate into modern web development workflows.

Dart-Sass is fast, but not the JS compiled version. Practically when we say Dart-Sass there are two options:

• Dart-Sass on Dart-VM
• Dart-Sass on NPM which is pure JS compiled version

I compiled Bootstrap 4 Sass file to CSS with Node-Sass, Dart-Sass and Dart-Sass(JS) and you can see the following result:

• In this particular case, two seconds is not a big deal; but consider Dart-Sass(JS) is nine times slower than Dart-Sass(Dart VM) and three times slower than node-sass.
• I had a project with +20 themes, it took 30 seconds with node-sass, but I tried to use Dart-Sass(JS), and it took a century!
• Although Dart-Sass(Dart VM) is the fastest but installing or integrating it is a bit tricky.
• And Node-Sass is considered deprecated.

I blogged about it here, you can read more about it here.

24/01/2021

As it's written in official node-sass github doc, node-sass is deprecated.

Warning: LibSass and Node Sass are deprecated. While they will continue to receive maintenance releases indefinitely, there are no plans to add additional features or compatibility with any new CSS or Sass features. Projects that still use it should move onto Dart Sass.

So I guess it would be better to chose dart sass if you plan long term or to stay up to date.

node-sass may be faster than dart-sass, but as of writing this dart-sass is the only library which implements the @use rule, which is strongly recommended over @import. According to the official sass-lang website:

What’s Wrong With @import? The @import rule has a number of serious issues:

• @import makes all variables, mixins, and functions globally accessible. This makes it very difficult for people (or tools) to tell where anything is defined.

• Because everything’s global, libraries must prefix to all their members to avoid naming collisions.

• @extend rules are also global, which makes it difficult to predict which style rules will be extended.

• Each stylesheet is executed and its CSS emitted every time it’s @imported, which increases compilation time and produces bloated output.

• There was no way to define private members or placeholder selectors that were inaccessible to downstream stylesheets.

The new module system and the @use rule address all these problems.

Additionally, @import will be gradually phased out over the next few years, and eventually removed from the language entirely.

In order to stay up-to-date with the best practices in Sass, you should use dart-sass (i.e. sass) for now.