就在今天，Sass 官方團隊正式宣布 Libsass 將棄用，以及基於它的 Node Sass 和 SassC，並且建議用戶使用 Dart Sass。
首先我們看下官方博客的一些回復（前半部分均來自官方博客 https://sass-lang.com/blog/libsass-is-deprecated），然后我們再來對 Node Sass 和 Dart Sass 做一個基准測試。讀完本文以下問題將會得到解答。
- 那么為什么會有這次改動呢？
- 之后 Node Sass 還維護嗎？
- Dart Sass 能滿足我們的需求嗎？
- Dart Sass 的性能如何？
- Dart Sass 帶來的好處和壞處。
背景說明
此次改動是在 Sass 核心團隊進行了大量討論之后，得出的結論，現在是時候正式宣布棄用 LibSass 和基於它構建的包(包括 Node Sass)。多年來，LibSass 顯然沒有足夠的工程帶寬來跟上 Sass 語言的最新發展 (例如，最近的語言特性是在 2018 年 11 月添加的)。盡管我們非常希望看到這種情況有所改善，但即使 LibSass 長期貢獻者 Michael Mifsud 和 Marcel Greter 的出色工作也無法跟上 CSS 和 Sass 語言開發的快速步伐。
主要包括以下四點說明
- 不再建議將 LibSass 用於新的 Sass 項目， 改為使用 Dart Sass。
- 建議所有現有的 LibSass 用戶制定計划，最終遷移到 Dart Sass，並且所有 Sass 庫都制定計划 最終放棄對 LibSass 的支持。
- 不再計划向 LibSass 添加任何新功能，包括與新 CSS 功能的兼容性。
- LibSass 和 Node Sass 將在盡力而為的基礎上無限期維護，包括修復主要的錯誤和安全問題以及與最新的 Node 版本兼容。
為什么棄用？
幾年來，Sass 一直處於一種模棱兩可的狀態，LibSass 在理論上是官方支持實現，但實際上從它的功能表現來看是靜止的。 隨着時間的流逝，越來越清楚感受到這種狀態對 Sass 用戶已經造成了切實的問題。 例如，經常讓用戶感到困惑，為什么原生 CSS 的 min() 和 max() 無法正常工作，可能會認為 Sass 整體存在問題，但是實際上是因為 LibSass 不支持該功能。
官方支持的 LibSass 不僅會給個別用戶帶來痛苦，由於 LibSass 不支持去年啟動的 Sass 模塊系統，主要相關的 Sass 庫由於擔心其下游用戶不兼容而無法使用它， 明確指出所有 Sass 用戶應該放棄使用 LibSass，我們希望使這些 library 的作者能夠更加切實地使用更多現代的功能特性。
LibSass 甚至抑制了 Sass 語言本身的發展。 我們無法繼續推進有關 treating / as a separator 的提議，因為他們編寫的任何代碼都會在 Dart Sass 中產生棄用警告或無法在 LibSass 中編譯。 通過將 LibSass 標記為已棄用，情況會變得更好，並且 Sass 在支持最新版本的 CSS 方面會變得更好。
"棄用"意味着什么？
我們之所以選擇使用"棄用"一詞，是因為它在編程社區中具有很大的分量，並強烈表明用戶應該開始計划放棄 LibSass。 但是，這並不意味着該項目已經完全死了。 LibSass 和 Node Sass 的首席維護者 Michael Mifsud 確認他計划繼續進行與過去幾年相同級別的維護。 這意味着盡管將不再添加任何功能（並且這樣 LibSass 會慢慢地逐漸偏離與最新 CSS 和 Sass 語法的兼容性 ），但將繼續無限期地發布維護版本。
可移植性和性能呢
LibSass 與 DartSass 相比有兩個主要優點：
- 可移植性：由於它是用 C++ 編寫的，因此可以輕松地將 LibSass 嵌入其他編程語言中並提供原生(native-feeling) API。
- 性能：通過 C++ API 調用 LibSass 與使用腳本語言直接編寫代碼的速度相比非常快。 特別是，這意味着 LibSass 在 JavaScript 中比 Dart Sass 編譯為 JS 的庫速度要快得多（盡管它可與 Dart Sass 的命令行可執行文件相媲美）。
我們正在使用 Sass 嵌入式協議來解決這兩個問題，該協議將 Sass 編譯器作為子進程運行，可以通過消息傳遞與任何主機語言進行通信。 嵌入式協議支持本地 Sass API 的所有功能，包括定義自定義導入程序和 Sass 函數的能力，同時還提供高性能的 CLI 應用程序。 Dart Sass 已經實現了嵌入式協議的編譯器端，並且正在積極開發 JavaScript 端。
Dart Sass
Dart Sass 可以編譯為純 JavaScript 編寫的 sass 軟件包上傳到 npm 。 純 JS 版本比獨立的可執行文件慢，但易於集成到現有工作流程中，並且允許你在 JavaScript 中定義自定義函數和導入器。
當通過 npm 安裝時，Dart Sass 目標是實現一個與 Node Sass 兼容的 JavaScript API 庫。完全兼容還在開發中，但是 Dart Sass 目前支持 render() 和 renderSync() 函數。但是請注意，在默認情況下，由於異步回調的開銷，renderSync() 的速度是 render() 的兩倍以上。
// 使用示例
var sass = require("sass");
sass.render(
{
file: scss_filename,
},
function(err, result) {
/* ... */
}
);
// OR
var result = sass.renderSync({
file: scss_filename,
});
基准測試
測試腳本倉庫: https://github.com/hua1995116/sass-benchmark
接下來我們分別來測試一下，Node Sass 以及 Dart Sass 同步以及異步的性能。
測試 Sass 文件: https://github.com/ElemeFE/element/blob/dev/packages/theme-chalk/src/date-picker/date-picker.scss
測試機型: MacBook Pro (Retina, 15-inch, Mid 2014)
Node 版本: v12.16.0
基准測試庫: benchmark
速度測試
說明: 利用 benchmark 進行基准測試
結果:
sass async x 14.01 ops/sec ±27.72% (55 runs sampled) sass sync x 28.83 ops/sec ±7.24% (63 runs sampled) node-sass async x 47.50 ops/sec ±3.10% (58 runs sampled) Fastest is node-sass async
說明: 值越大，代表速度越快，性能越好。
內存測試
說明: 三個方法各操作 50 次后的情況。
結果:
可以看到 Node Sass 性能確實非常好，也是官方提到的優勢。而 Dart Sass 同步的方法 比 異步方法 性能略高 2 倍左右。
總結
總體來看 Dart Sass 面向未來，支持各種新的特性。Dart Sass 純 JS 的方式也可以讓我們擺脫被 Node Sass 編譯支配的恐懼，不用再擔心 Node Sass 安裝不成功的問題了，並且 Dart Sass 也在積極地處理它的性能問題。