忽略其他特性，Sass 对自己的定位首先是一个预处理器。其最主要的竞争对手包括 [LESS](http://lesscss.org/)，一个基于 Node.js 的预处理器，因著名 CSS 框架 [Bootstrap](http://getbootstrap.com/) 的使用而声名鹊起。此外还有 [Stylus](http://learnboost.github.io/stylus/) ，一种对形式无所限制的 LESS 版本。它是一种无论你想怎么样使用，大都能顺利转换成 CSS 的程序语言。 _为什么选择 Sass 胜过 LESS 以及其他预处理器？_，这始终是一个待解决的问题。就在刚刚，我们还建议在 Ruby 项目中使用 Sass，因为 Sass 初创于 Ruby 并且在 Ruby on Rails 中运行良好。现在随着 LibSass 与 Sass 的逐步接近，上述建议显然已经不再绝对和必须。 我之所以喜欢 Sass 源于它最大程度保留了 CSS 的原生特性。Sass 的设计基于非常坚实的设计原则：大部分的设计顺其自然的来源于核心设计师们的信条，比如添加额外的功能会增加语言的复杂度，但以实用性衡量极具价值的话便得以保留；同时，使用 Sass 来美化一个块级元素，那么美化前后的效果应该是可预见和可推理的。同时，Sass 比其他预处理器更加关注细节。据我所知，核心设计者们非常关心 Sass 与 CSS 在细节上的一致性，并确保所有的常用方式具有高度一致的表现。 换言之，Sass 并不想成为一个通过在编程语言顶层添加特殊功能实现有关用户逻辑处理的预处理器，以取悦于像我一样喜欢傻瓜式编程的程序员。它更准确的定位是一款软件，旨在解决实际问题。通过提供实用功能改善 CSS 的短板。 预处理器之外，我们还需要提及一下后处理器。得益于 [postCSS](https://github.com/postcss/postcss) 和 [CSSNext](https://github.com/cssnext/cssnext)项目，后处理器最近几个月得到了显著曝光。后处理器几乎等同于预处理器，稍有不同的是它专注于实现那些即将出现在 CSS 语法中的特性。 你可以认为后处理器是一种腻子脚本，用来支持尚未被浏览器实现的 CSS 功能。举例来说，你可能会像 [CSS 规范](http://dev.w3.org/csswg/css-variables/)中描述的一样使用变量，然后用后处理器编译样式表，在这个过程中后处理器只会找出变量出现的地方并替换成真实值——Sass 也是这么做的。 后处理器背后的思维是，一旦浏览器支持了新的特性（比如 CSS 变量），后处理器就不再做这方面处理，而是让浏览器执行相关处理。 虽然在当下提供对未来语法功能的支持是一件很了不起的事情，但我还是喜欢在大多数的工作中使用 Sass。当然，在一些情况下我认为后处理器比 Sass 更适合，比如 CSS 前缀。稍后我们会讲到这个问题。 ### 扩展阅读 * [LESS](http://lesscss.org/) * [Stylus](http://learnboost.github.io/stylus/) * [cssnext](https://cssnext.github.io/) * [PostCSS](https://github.com/postcss/postcss)