CSS 的預處理程序（Sass、LESS、Stylus 等）分別都有哪些優缺點？

01-08

可能開始題目有歧義，補充下：是說這些預處理器各自的優缺點，不是說預處理器這個大的概念。沒提到的預處理程序歡迎補充。

CSS Tricks 等網站上也有一些對比特性的的文章，但總覺得只有介紹，沒有比較。

這問題 @一絲邀請了很久了，終於寫了一篇文章詳細說說這個問題：《再談 CSS 預處理器》。

三種CSS 預處理器（框架）

歷史：

SASS2007年誕生，最早也是最成熟的CSS預處理器，擁有ruby社區的支持和compass這一最強大的css框架，目前受LESS影響，已經進化到了全面兼容CSS的SCSS。
LESS2009年出現，受SASS的影響較大，但又使用CSS的語法，讓大部分開發者和設計師更容易上手，在ruby社區之外支持者遠超過SASS，其缺點是比起SASS來，可編程功能不夠，不過優點是簡單和兼容CSS，反過來也影響了SASS演變到了SCSS的時代，著名的Twitter Bootstrap就是採用LESS做底層語言的。
Stylus，2010年產生，來自Node.js社區，主要用來給Node項目進行CSS預處理支持，在此社區之內有一定支持者，在廣泛的意義上人氣還完全不如SASS和LESS。

LESS Sass

LESS是受Sass啟發而開發的工具，它列出了如下開發的理由：

「為什麼要開發一個Sass的替代品呢？原因很簡單：首先是語法。Sass的一個關鍵特性是縮進式的語法，這種語法可以產生柱式外觀的代碼。但是你需要花費時間學習一門新的語法以及重新構建你現在的樣式表。
LESS給CSS帶來了很多特性，使得LESS能夠和CSS無縫地緊密結合在一起。因此，你可以平滑地由CSS遷移到LESS，如果你只是對使用變數或者操作感興趣的話，你不需要學習一整門全新的語言。」

Stylus

Stylus相對前兩者較新，可以看官方文檔介紹的功能。

1.來自NodeJS社區，所以和NodeJS走得很近，與JavaScript聯繫非常緊密。還有專門JavaScript API：http://learnboost.github.io/stylus/docs/js.html

2.支持Ruby之類等等框架

3.更多更強大的支持和功能

總結：Sass看起來在提供的特性上佔有優勢，但是LESS能夠讓開發者平滑地從現存CSS文件過渡到LESS，而不需要像Sass那樣需要將CSS文件轉換成Sass格式。

Stylus功能上更為強壯，和js聯繫更加緊密。

引用：使用LESS或Sass重構CSS代碼

Ruby China | SASS 和 Compass 指南

Stylus-NodeJS下構建更富表現力/動態/健壯的CSS ? 張鑫旭

話說今天剛好看到一篇： http://css-tricks.com/sass-vs-less/

自己不太喜歡用，CSS 還沒讓我頭痛到需要預處理＝＝

我用Stylus，得益於以下幾點：

1. 簡短直觀，縮進讓CSS的層次非常直觀

2. At 屬性引用可以減少維護量

3. 函數和Mixin，重用的利器

結合nib之後，生活會更好

之前翻譯過一篇文章 http://www.qianduan.net/an-introduction-to-less-and-comparison-to-sass.html

只是現在不太喜歡用這些工具了。它們沒有本質區別，只是在css、html之外自己做了一套規則，目的都是提高代碼效率，DRY思想的典型實踐。

不用它們的原因是學習成本有點高，團隊協作成本也隨之提升。

現在的團隊有良好的模塊化思想，常用模塊會整理成公用組件，加上zencoding（現名emmit），IDE用sublime或者idea ，效率還是蠻高的。

去年在《程序員》雜誌上發表過一篇文章，有興趣的同學可以看看：CSS預處理器——Sass、LESS和Stylus實踐【未刪減版】　雖然文章沒有系統剖析出三者的優缺點，但從具體的功能點上或許能找到一點答案。雖然最早接觸的是LESS，但我現在喜歡Sass。他真的很有意思

我用sass開發css，用pug開發html，說說我的感受，這類預編譯語言最大的好處是讓身為文本標記語言的html和css有了邏輯。尤其是3015年12月公布的sass3.4.21以ruby為腳本語言開發的若干新api，比如對於css類選擇器的操縱有了進一步提升，強大的指令等等。讓我感覺我在架構css的ui框架時能把sass斜橫jquery，很爽造嗎？我現在正在推廣我們組內的前端開發使用我這套方法呢，不用打入冷宮捏。

目前感覺不好的地方是預編譯語言不能即時預覽，但可以通過配置watch（）task監聽到，還有就是sass3.5出來以後api更多，開發工具貌似我沒找到有對sass api做提示的（或許我可以考慮開發一個嘻嘻）名字不方便記憶，老得查文檔。

之前樓上貼出的比較文章有點老，這裡貼一篇 Less 的貢獻者 Luck Page 寫的對比（有偏向）Scott Logic

基本上，Less 的設計思路偏向原生 CSS，而 Sass 和 Stylus 更偏向計算機語言（分別是 Ruby 和 JS）。所以，可能，前者更適合前端，後者適合工程師。

補充幾點除了風格以外的看法。【以 stylus 的角度來說】

比較有意思的是， stylus 更加註重對 javascript( http://learnboost.github.io/stylus/docs/js.html ) 的利用。當用戶覺得寫 stylus 函數遇到了過於複雜或者無法測試，stylus語法不支持等需求時，也可以直接用 js 來實現這個函數並且在 stylus 中調用。

其次從編譯器源碼上來看：stylus 應該比 less.js 更有條理，感覺如果未來社區添加功能的話，stylus 的源碼添加起功能來會更簡單，同樣，目前 stylus 的功能也更複雜。

stylus 和 sass 另一個區別在於 sass 本身會建議，以下劃線(_) 打頭的文件在靜態資源打包的時候不會被編譯成 .css 文件【只是作為一種 import 存在】。而 stylus 沒有這方面的規範。

同時寫過 stylus 和 sass，就語法簡潔來看， stylus 在這方面佔了很大的便宜。

最近也在看less，感覺CSS本就是比較簡單的語言，而用less反而把簡單的東西複雜化了，雖然less加入了模塊化的東西，看似方便管理了，可是在多人合作的團隊中我不推薦使用，如樓上神飛所說，只要團隊中的成員都有模塊化的思想，並有統一的規範，less其實沒有使用的價值，只是在移動開發端不知道是否能更有用武之地？

個人覺得，其實根據這些社區的各種活躍，以及相互借鑒，這些預處理工具本質上都會趨於一致，所以不管你是用Sass, Less還是Stylus，本質上區別都不大，就是各家語法命名會有些區別而已。