SCSS和LESS相比有什麼優勢？Bootstrap 4也要改成SCSS默認的了

01-08

我個人一直是傾向less。更像原生的CSS。@符號比$符號更加看起來更加親切在CSS中。
一直沒有分清楚兩者區別，變數，嵌套，mixin和函數兩個都有的。
為什麼感覺原來越多的人傾向SCSS的呢？國內也是的。大漠老師啊。
bootstrap從2的默認less到，3的scss複製，到未來4的scss默認。應該有原因的吧？

恰巧，前段時間我在中國css-conf. 做了一個關於預處理器的分享 CSS預處理器 - 鄭海波，有些想法還算清晰。

我算是補充下 @顧軼靈的回答, 來解答下題主的問題。

我個人一直是傾向less。更像原生的CSS。@符號比$符號更加看起來更加親切在CSS中。

從詞法角度講， LESS的確是最接近CSS的，但是僅限於如此。但是不幸的是它佔用了 @at-rule 關鍵字作為了變數標識符，使得功能擴展性大大降低

比如SCSS等預處理器可以輕易引入 @extend 來實現繼承功能（從語法上是符合規範的）

.foo{} .foo-lg{@extend .foo}

但LESS就不得不在選擇器上面開刀，引出了 :extend 這樣的自定義偽類

nav ul { :extend(.inline); background: blue; } .inline { color: red; }

當然在表現上會有所區別，比如嵌套結構的繼承，但是大體實現的相似的功能。但是從語言角度角度講，擴展@at-rule 比擴展選擇器要更健康一些，也更符合 css原本的設計。再者，假如你要引入其它功能呢？比如循環、條件。大家可以腦補下LESS的遞歸解決方案. 靈活性不可同日而語，而這個缺陷在LESS第一版出現時，就已經註定了，所以LESS作者肯定不是一個語言設計的大師。

一直沒有分清楚兩者區別，變數，嵌套，mixin和函數兩個都有的。為什麼感覺原來越多的人傾向SCSS的呢？

答案就是語言能力，LESS的設計限制了它的語言擴展性。預處理器80%的功能都是類似的，但是往往一些細微的區別就可能導致你選型的不同。

首先LESS是沒有函數支持的，函數支持並不是一個獨立存在，它需要有完整的內部數據類型定義，參數、條件或循環控制、返回值定義等等... LESS顯然沒有提供所有的這些。正是因為如此，這也是預處理器語言能力的分水嶺.

或許有些人說，函數完全可以由js來實現，我可以操作AST來實現具體函數，大家可以腦補下為什麼現在React配合JSX會讓我有舒爽的感覺，而React通過JS直接聲明函數嵌套就乏味的很，這就是DSL（領域專屬語言）帶來的魅力，它是一個更高級的抽像(比介面封裝更高級)，它隱藏了內部細節，而只暴露了領域模型的「外衣」供你使用，比如你可以直接使用 1+$width, 使用場景非常簡單。但是從語法分析和解析角度，並不是所有人都可以輕易通過生成AST和操作AST來解決這個加法的簡單問題的。

並且函數直接在預處理語言中定義還具有天然的跨（運行時宿主）語言特性.

bootstrap從2的默認less到，3的scss複製，到未來4的scss默認。應該有原因的吧？國內也是的。大漠老師啊

我記得bootstrap5 號稱可能要使用postcss, 題主是否也要追呢？一個良好的CSS組織架構配合LESS其實現在應付絕大部分的前端工程也絕對沒有問題，關鍵你是否真的了解自己的需求。

再談 CSS 預處理器

已改用sass

---------------------------

我也更傾向less，而且項目中都是less

可能是讓人不習慣的「@"頭吧，讓人寫個代碼就像請一堆神仙下凡似的。

它們的代碼都看過一些，感覺 less 的代碼有腐爛的傾向，不知道是不是這個原因。

個人傾向LESS，雖然能力較弱，團隊內部推廣，完全沒有學習成本。方法(或者只能稱之為css模板片段)定義簡單、繼承直接一個選擇器就完事兒了，嵌套的基本功能支持也很好。如果真的要很複雜的邏輯，我寧肯使用另一門純粹的模板語言。

國外大神推薦postcss 而且目前看來material ui 比bootstrap適合react太多後者死於全局變數

這是sass吧，sass的功能比less強好多，我也是less轉sass了，還有就是less的變數符@並不討程序猿喜歡，還是sass的$一見如故。

從個人感受來說，我最早知道的CSS預編譯器是SASS，不過首先使用和長期使用上來說卻一直是LESSCSS。

原因有幾點：

學習成本：從代碼風格上來說，Less的風格相對於Sass來說，對CSS更具有親和性，也更好地繼承了CSS所帶來的優勢。

預編譯方式：最早SASS需要安裝ruby，而LESSCSS使用node

Bootstrap的首選：Bootstrap3使用了LESS作為首選開發方式

其他：

前面說的3點中的後2點可能有些過時，但其實就第一點來說Less足夠秒殺Sass。

關於循環的問題，css中使用循環的思路來解決樣式問題，從思維角度來說，就是應該限制這樣的不是很優選的使用方式。

關於 @鄭海波，所說的Less內部代碼不合理的情況，對於使用者來說，使用時無需太多考慮Less項目的實現方式。內部的實現方式可以重構重寫，甚至可以用新的項目來重新實現。

我認為Sass不會是Less的替代者

不是說4更傾向於sass？

引用變數之類的小細節就不用說了吧，我感覺主要是sass里封裝了好多方法，可以直接拿去作為微型js來用，我覺得H5這麼火也是和HTML+js有很多大關係吧

根據工作需要，蘿蔔白菜。把直接less用js渲染慢的問題放大，真的也是醉了。他只是多了一個場景而已，實際工作場景中沒多少這樣用的，lessc一下就行了。

Less的編譯器是node寫的，Sass的編譯器是ruby寫的，這點特蛋疼……

不過現在sass好像也有node寫的編譯器了？