原文：Mixins Are Dead. Long Live Composition

当 React 0.13 推出的时候，大家都震惊了。

它的开篇表达得很明确，mixin 正在逐步退出历史舞台：

不好意思，React ES6 将不再支持mixin，否则有悖 JavaScript 语义化的初衷。

在 JavaScript 中我们找不到通用的标准来定义 mixin，事实上，ES6 也摒弃了不少支持 mixin 的特性。语义混乱的类库已经很多了。尽管我们认为应该有一个统一的方法来定义 mixin，便于对 JavaScript 各种“类”的操作，但 React 并不打算这么做。

mixin 始终会来的，某些人可能会有这样的理解。但实际上， Sebastian Markbåge，伟大的API终结者，也不太看好 mixin：

“坦白说，mixin 其实是一个后门，它可以绕过系统对某些复用的限制，但是语义化的 React 不该是这样的。让组合更加便捷较之随心所欲地 mixin 应该享有更高的优先级，对 React 来说，这才是正事。”

为什么要用 mixin？mixin 解决了什么问题？我们是否可以换一种无继（Tong）承（ku）的方式去解决这些问题？

通用函数

这个例子举得稍微有点脑残。与其用 mixin 的方式去共享通用功能，直接将其提取出来并模块化，需要的时候直接引用不是更好么？

生命周期和状态选择

这是 mixin 的主要用例。如果你对 React 的 mixin 系统还不是特别熟悉，可以这么理解，它"合并"了生命周期钩子并且更加智能。假如同时使用了组合以及一些 mixin 去定义 componentDidMountlifecycle 钩子，React 会自动合并它们以保证每个方法都能被调用。类似地，使用一些mixin也能作用于 getInitialState 方法。

在实践中，这是唯一体现 mixin 用处的地方。mixin 可以向 Flux Store 订阅组件的状态或者作用于更新后的组件 DOM 节点。任何一个组件扩展机制均能获得组件的生命周期，这一点是绝对有必要的。

然而mixin还是有不少弱点：

CSS 预处理器是什么？一般来说，它们基于 CSS 扩展了一套属于自己的 DSL，来解决我们书写 CSS 时难以解决的问题：

• 语法不够强大，比如无法嵌套书写导致模块化开发中需要书写很多重复的选择器；
• 没有变量和合理的样式复用机制，使得逻辑上相关的属性值必须以字面量的形式重复输出，导致难以维护。

所以这就决定了 CSS 预处理器的主要目标：提供 CSS 缺失的样式层复用机制、减少冗余代码，提高样式代码的可维护性。这不是锦上添花，而恰恰是雪中送炭。

网上已经有不少对比目前最主流的三个预处理器 Less、Sass 和 Stylus（按字母顺序排名）的文章了，但是似乎都不是很详细，或者内容有些过时。下面我会更详细地探讨一下这三种预处理器的特性和它们的差异。

下面主要会分为如下几方面来讨论：

• 基本语法
• 嵌套语法
• 变量
• @import
• 混入
• 继承
• 函数
• 逻辑控制

事先声明一下，平时我在开发中主要使用的是 Less，所以可能对 Sass 和 Stylus 的熟悉程度稍差一些，比较时主要参考三者官网的语言特性说明，有一些正在开发的功能可能会遗漏。

本文中对 CSS 语法的话术与 MDN 的 CSS 语法介绍一致。