Cole Peters 谈论当前的预处理器格局以及放弃 Sass 而转向 PostCSS
… 以下是与典型的预处理器相比，我们使用 PostCSS 和 cssnext 所获得的优势
- 极快的编译时间（在我的示例中，速度提高了约 800%）
- 用 CSS 编写的源代码，根据当前和即将发布的规范定义，这意味着
- 没有特定于供应商的语法（除非我们自己编写——小心！），因此
- 任何对 CSS 略有了解的人都可以立即理解源代码，并且
- 源代码具有面向未来、可移植性强以及易于诊断和调试的特性
PostCSS 和 cssnext 当然是有趣的项目，值得关注。 不过，这里的所有主要观点都很容易被反驳…
- 编译速度需要多快？ 我甚至在大多数项目中都没有使用 libsass，速度从未困扰过我，而且一旦我切换，这似乎将达到构建步骤所需的最快速度。
- 我们知道规范会发生变化。 这种情况一直都在发生。 基于非最终规范来构建语法似乎很奇怪。 如果规范发生变化会怎样？ 您是否会更改语言并让现有代码失效？ 这样如何才能面向未来？ 或者支持所有过去的格式？ 这意味着该语言并非真正基于未来的 CSS，而是基于任何被考虑过的实验性想法？
- 可选的附加组件系统鼓励每个人的设置略有不同。 这是否使其实际上降低了可移植性？ 并使社区更难以形成？
- 为什么它更易于理解？ 我不确定仅仅因为代码可能有一天会成为语言的原生部分，它就自动更容易理解。 从我听到人们的说法来看，像变量这样的东西比标准的 Sass 变量更难理解。 更不用说，在预处理步骤中不可能完全模拟原生行为，这一点有点令人困惑。
所有这些都是值得考虑的有趣的事情。 就我个人而言，我喜欢预处理器尽可能像 polyfill 一样的想法，但我也认为应该拥抱而不是害怕抽象。