SCSS和LESS相比有什么优势？Bootstrap 4也要改成SCSS默认的了

恰巧，前段时间我在中国css-conf. 做了一个关于预处理器的分享

，有些想法还算清晰。

我算是补充下

的回答, 来解答下题主的问题。

我个人一直是倾向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其实现在应付绝大部分的前端工程也绝对没有问题， 关键你是否真的了解自己的需求。