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

Question

When creating a new project with CLI (v3.7.0), there is an option to choose between dart-sass or node-sass compiler.

How do these compare to each other, to be more specific than declared in Vue docs?

A Tip on Sass Performance

Note that when using Dart Sass, synchronous compilation is twice as fast as asynchronous compilation by default, due to the overhead of asynchronous callbacks. To avoid this overhead, you can use the fibers package to call asynchronous importers from the synchronous code path. To enable this, simply install fibers as a project dependency:

npm install -D fibers

Please also be aware, as it's a native module, there may be compatibility issues vary on the OS and build environment. In that case, please run npm uninstall -D fibers to fix the problem.

? Pick a CSS pre-processor (PostCSS, Autoprefixer and CSS Modules are supported by default): (Use arrow keys)
❯ Sass/SCSS (with dart-sass)
  Sass/SCSS (with node-sass)
  Less
  Stylus

EDIT 2020/01: Vue CLI 4.2.2 create new project is still suggesting dart-sass as the first option before node-sass. Yet it has been established here that node-sass is the more performant choice, and almost nobody uses dart-sass (ccleve's comment).

EDIT 2020/09: As Ali Bahrami updated his extensive answer, dart-sass is the preferred choice as node-sass is being marked as deprecated.

Too bad dart-sass in it's a JS-compiled version has poor performance. However, it's developers are well aware of this, and are working towards greater performance as stated in this issue.

Answer 1

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.

Answer 2

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.

Answer 3

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.