忽略其他特性，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)