But it was again rewritten in Dart and the Dart version is now the reference implementation. And they did that because for a lot of Sass users, working with Rub

But it was again rewritten in Dart and the Dart version is now the reference implementation. And they did that because for a lot of Sass users, working with Ruby sucked, simply because they didn't have the tooling and knowledge built up to handle it correctly. Libsass's main "claim to fame" is that just about all languages (including Javascript on the backend) can interop with C/C++ pretty effortlessly. The rewrite was more about enabling more and more users to use the languages and package managers they are used to rather than about speed (especially since the Dart SASS implementation is quite often FASTER than the libsass version!) Take a look at the Sass perf benchmarks below for more info: https://github.com/sass/dart-sass/blob/master/perf.md https://github.com/sass/dart-sass/blob/master/perf.md Although keep in mind that a lot of the performance benefits go away when you run Dart Sass via javascript compilation in regular node. But IMO that gives you a lot of choice. You can get the best performance by installing the Dart toolchain and running it "natively" on dart, or you can run it via node for "okay" speed in most cases, or you can deal with native compilation via C/C++ and libsass for a mix of both. It's a nice setup they have going on over there!