几个月前，我们 启动 了关于 CSS 预处理器语法的投票。它引发了 相当多的讨论，并获得了近 13,000 份回复。让我们通过查看收集到的数据来总结一下。
我把所有数据都放到了这张图表中
将本文的其余部分视为该图像的替代文本。在近 13,000 份回复中，细分如下
| Sass | 5% |
| Scss | 13% |
| LESS | 23% |
| Stylus | 3% |
| 我不喜欢任何一个 | 7% |
| 我没有任何偏好 | 2% |
| 我从未尝试过任何一个 | 46% |
| 其他 | 1% |
由此我们可以推断，“大多数”人尝试过或当前正在使用 CSS 预处理器（54%）。我对这个数字的想法一直在变化。一方面，考虑到最近关于它们的讨论如此之多，而且这次投票代表了访问并与名为“CSS-Tricks”的网站互动的人，这个数字似乎有点低。另一方面，开始使用预处理器确实会涉及一些不方便的准备工作。您必须在本地工作。您需要让整个团队都参与进来。您必须下载并运行新的软件。它不像编辑常规 CSS 那样，只需打开文本文件并进行编辑/保存。我认为，54% 的人足够关心自己的工作流程，愿意尝试这一点，这相当令人鼓舞。
我们对 46% 从未尝试过的人知之甚少，但我推测他们分为以下几类：“我不需要这个”，“我甚至不知道有它们”，以及像 这样的人：“真正的男人不需要预处理器。”
从这里我们可以进入投票的核心：找出最受欢迎的语法是什么。在尝试过预处理器的 54% 的人中，其中 83% 有偏好。另外 17% 或者不喜欢任何一个，或者没有任何特别的偏好。我们不知道这些人中有多少人实际尝试过几个并选择了最适合他们的那个。当然，外部因素会影响这一点。例如，他们正在一个 Rails 项目上工作，并且 Sass 与之一起提供。他们喜欢它，所以他们一直坚持使用它。或者，他们正在使用 Twitter Bootstrap（它是用 LESS 构建的）的项目上工作。他们喜欢它，所以他们一直坚持使用它。
在尝试过预处理器并有偏好的人中，我们可以按语法进行细分。LESS 是最受欢迎的，占这些人的 51%。Sass 语法加起来占 41%。Stylus 占 6%，其他（例如自定义 PHP 处理器）占 2%。
在偏好 Sass 的人中，71% 喜欢 scss 语法（更像 CSS），29% 喜欢 sass 语法（依赖空格，没有大括号或分号）。
一年或两年后重新审视这些数字将会很有趣。所有投票 都存档在此处。很快就会有新的投票。
有趣。表明了为一项技术配备“杀手级应用”的重要性——在本例中是 Bootstrap。我更喜欢 Sass，但 Bootstrap/LESS 组合显然对使用率产生了巨大影响。
……这非常重要。正如 jQuery 本质上赢得了 JavaScript 库之战并成为事实上的行业标准一样，CSS 预处理器也将发生同样的事情。
我认为 Sass 比 LESS 更好，原因有几个，但最终我们必须学习哪一个将取决于市场份额。现在它们几乎相等（当它将 SCSS 和 SASS 分开时，信息图有点误导，因为它们本质上是相同的预处理器）。在某个时刻，其中一个将占据主导地位。
我不认为 jQuery 的类比在这里适用。jQuery 是一种“最终”产品，包含在大多数网站中。另一方面，sass 或 less 作为第三方工具参与到开发过程中。不同语言之间没有真正的竞争。只要它们能够获得足够的支持，它们就会存在。关键在于社区，无论是 jQuery、wordpress、sass 还是 less。
由于 @Balazs 指出的原因，无法与 jQuery 进行比较。类似的一点是 Less 有一个免费的简单 GUI，并且支持 Twitter bootstrap。
尽管预处理器已经存在一段时间了，但它仍然是一个新兴领域。Stylus 通常由 node.js 开发人员使用，SASS “通常”用于 Ruby on Rails，并且您会发现 LESS 更受 php 开发人员使用，您可以将编程语言的市场份额与 CSS 预处理器相匹配。
显然，这些工具中的每一个都有一个命令行界面，允许您将它们与您选择的任何开发堆栈一起使用，但最终从开发工作流程的角度来看，从框架支持的角度来看，通常最好使用您编程语言中最受欢迎的预处理器。例如，stylus 有“nib”，它就像 compass。您可以将 nib 用于任何框架，但对于 node 项目的实现是 NPM 安装和 1 行额外的代码，而我需要设置正确的目录结构和编译构建才能在非 node.js 项目中使用 nib。
我心中真正的问题是，真正的专业人士更喜欢什么。这并不是说 css-tricks.com 上没有专业人士，但同时，我们需要关注行业巨头、大型互联网公司和大型网络开发机构，并询问他们为什么使用他们使用的工具。
SASS 对我来说似乎很好，我使用 LESS 的唯一原因是 SASS 强制我使用 Ruby。
无需使用 Ruby 或触摸任何 .rb 文件即可使用 Sass。在 Mac 和 PC 上都有大量可用的 GUI，以及正在开发中的第三方编译器（如 libSass 和 PHPSass），如果您不喜欢在后台运行 Ruby 的话。
是的。CodeKit for Mac 非常棒。还有 Fire.app 或 Scout.app 。个人最喜欢 codekit，但 Scout.app 是免费的。
我将假设 LESS 更受欢迎是因为 Twitter Bootstrap 的普及。Sass 可能是未来，但在我看来，LESS 是一个更容易上手的预处理器。
@todd 是的……说得很好。
@Todd：同意！
我还没有开始使用任何预处理器，因为它涉及学习另一种语言格式。在这一点上，我正在学习 PHP 和 MySQL/RDBMS 的课程。当我完成这些课程并完成了 ActionScript3.0 和我的作品集课程后，KineticsJS 就耐心地等着我。一旦我觉得自己对 KineticsJS 已经足够熟悉了，我就会开始接触预处理。
我已经下载并安装了 SCSS/SASS、Ruby 和 Rails。我只是现在没有时间处理所有这些。我确实喜欢嵌套 CSS 和 OOCSS 的想法，所以我会尽快开始学习。它只是还没有排到我的优先级列表的最前面。
现在我更关注常规 CSS、学习 CSS 动画，以及为什么 hsla/rgba 在 CSS 渐变中似乎有一半时间不起作用。
奇怪的是，使用（或撰写关于）Sass 和 SCSS 的人比使用 Stylus 的人多得多，因为 Stylus 在 GitHub 上实际上有更多的关注者。
你们应该看看 Stylus，它与 nib 结合起来非常棒。我最近从 LESS 切换到 Stylus 了。 :)
我原本以为 SASS + SCSS 会以很大的优势胜过 LESS。但我很高兴。我更喜欢 LESS，所以也许结果会激励一些优秀的人基于此预处理器创建有趣的工具，因为目前 LESS 似乎有些被遗忘了。
我从未使用过任何类型的预处理器，这激励我迈出了第一步。我也很惊讶有 46% 的人和我处于同一条船上。
我一开始使用 LESS，因为它更容易上手，因为它使用 JavaScript，此外，还有 PHP LESS，允许基于 PHP 的 CMS 使用它。
但在切换到 Sass 以及 Compass 后，在我看来，Sass 比 LESS 更好。
1. 您可以使用循环、if 语句等实现真正高级的逻辑。
2. 文件助手非常棒，比如 image-url、image-width、image-height 等。
3. 开发输出模式包含源文件和行号的注释。
4. 包含文件会神奇地移动到样式表的顶部。
我发现 LESS 更自然、更简洁，也更适合初学者，但如果投入足够的工作，使用 SCSS/Sass 会因为某些特性（比如 Compass）而变得更好（而且使用 $ 符号的变量更漂亮）。
我两种都用过，而且仍然没有偏好（投票的时候我选的是 LESS）。
我昨天刚从 LESS 切换到 SASS（SCSS 变体），根据我所做的所有研究，它似乎是一种更成熟、更完善的语言。逻辑处理似乎要好得多。
在过去的一天里，我花了几个小时将我的代码库（样板、响应式网格、mixin）重写为 SCSS，我不得不说 LESS 语法更容易使用，SASS 可能与 LESS 非常相似，但是由于它是两者中较旧的语法（SASS/SCSS），我犹豫是否要采用它。
我可以看到 SASS 的强大功能是媒体查询处理和使用 Compass 的能力，我还没有迈出这一步，但将来有机会可以探索。
我认为有一件事在两者之间没有意义作为比较因素，那就是编译，LESS 可以使用 JS 进行服务，但不要这么做，它会占用大量内存并创建 JS 依赖项。CodeKit 兼容 LESS/SASS/Haml/CoffeeScript/Compass，并且会自动监视文件更改并在后台编译……如果 Windows 用户感兴趣，LiveReload 也可以实现类似的功能（目前处于测试阶段），对于 LESS，还有 SimpLESS。重点是，使用任何一种方式你都能找到简单的方法。
选择一个并开始使用，它会节省你**数小时**的工作流程，选择哪一个并不重要，你可以轻松更改……只要尝试一下。
也许是时候在这个网站上写一篇关于什么是预处理器以及它们能为你做什么的好文章了，让那 46% 的人（我在这些统计数据中）加入进来。
你可以从这里开始：<a href=”https://css-tricks.org.cn/video-screencasts/111-get-yourself-preprocessing-in-just-a-few-minutes/”>这里</a>，就在这个网站上。
他们确实写过关于两者之间区别的文章。https://css-tricks.org.cn/sass-vs-less/
Stylus 是 express 的一部分，express 是一个 Node 模块，也许这就是它在 Github 上有更多关注者的原因。
我从未尝试过 Sass，但我会去尝试，我从 Less 开始，非常喜欢它，Sass 看起来更有趣，Stylus 真是太棒了！
我不得不说，使用 Mac 版的 LiveReload 使使用 SCSS 变得轻而易举！我之前一直使用终端，但现在由于 LiveReload，我甚至都不用考虑它了——而且 Windows 也有一个测试版——我认为如果你想开始使用 SASS/SCSS，那就试试 LiveReload！ :)
23% 的人不在乎网站性能。
在共享主机或甚至基本的 VPS 上调试一个基于 LESS 的网站，看看与 SASS 的区别。
谁关心网站优化应该使用
预编译的 CSS 预处理器。我个人使用 SASS/SCSS 和 Compass。
LESS 确实有能力使用 JavaScript “动态”处理，但我敢打赌，绝大多数使用它的人都是像使用 Sass 一样使用它，即在部署之前进行预编译。我只是想澄清这一点。如果人们愚蠢地使用它，那不是 LESS 的错=)
杰森，有一些像 http://wearekiss.com/simpless 这样的开发工具类似于 sass –watch
我认为拥有 JavaScript 纯粹是为了快速进入 Less，而无需安装任何软件。
大多数正在考虑 Less/Sass 的严肃开发者都会理解为什么使用客户端编译器是一个非常糟糕的主意。
@Ben 非常好，之前没见过这个。同意不应该让客户端编译代码，尤其是在移动设备上。
@Chris 你们之前在任何关于 LESS 的文章中讨论过这个吗？
@克里斯
LESS 的主导地位来自一系列因素。
1. 被“所谓的网页设计大师”所采用，这些大师诱导了许多懒惰的“有抱负的网页设计大师”加入。
2. Ruby 和 Rails 的增长。
我接受你的赌注，我认为大多数开发者都使用动态生成的 CSS 代码
抱歉，克里斯，我只是想纠正你的一点小问题：56% 甚至不接近“大多数人”。事实上，在我看来，这表明近一半的受访者从未尝试过预处理器。
我还要补充一点，当我回答调查问卷时，我也属于这些人，但从那以后，我下载了 Compass，并且非常喜欢它。不能说它改变了我的生活，但仅仅添加变量就产生了很大的不同（不必在代码中搜索客户希望我到处使用的“蓝色”），因此它是值得的。
总之，重点是，你离“大多数”还有很长的路要走，但像你之前比较 LESS 和 SASS 的文章那样，突出使用预处理器的理由有助于提高认识，并将像我这样的人介绍给新的东西，所以这是一个好处。在 6 个月后再次运行它，看看数字是如何改善的。
哈哈，“提高认识”……就像编写 CSS 是艾滋病，而 CSS 预处理器是治疗方法。
顺着这个思路——46% 的人没有使用，7% 的人不喜欢，这意味着实际上 53% 的人没有使用它们。这意味着不到一半——绝对不是“大多数人”在使用它们。我在工作中使用 SASS，所以我并不属于那一类人，但这确实意味着你的帖子充其量是不真诚的=)
好吧，不，“提高认识”指的是“向人们介绍新的东西”。我不知道你从艾滋病的类比中得到了什么，对我来说太聪明了。但只有白痴才会认为 SASS 是新的，对吧？
在我看来，对调查问卷做出回应的人通常会是那些在学习网页开发的优缺点方面发挥更积极作用的人。我相信有很多定期访问这个网站但没有做出回应的人。
话虽如此，我认为这些调查结果确实很有启发性，感谢与我们分享。
我想知道人们在大部分时间里使用的是什么，而不仅仅是他们最喜欢的。不确定这是否会改变人们回答问题的方式。虽然我可能尝试过 Sass 和 Less，并且更喜欢 Less 而不是 Sass，但这并不一定意味着我大部分时间都在使用这两者中的任何一个。也许我是在吹毛求疵？
简单地说，LESS 占据主导地位是因为它在 Windows 上有一套强大的工具。当然，在 Windows 上安装 Ruby 并使用 SASS 并不难，但用户想要的是快速有效的工具。我更喜欢 SASS，但我只会使用 LESS，因为它在 Komodo Edit 和 Visual Studio 中通过扩展提供了很好的支持。
正如我在 Reddit 上所说，LESS 很可能已经赢了，因为它拥有强大的工具集。
已解决！Fire.app 或 Scout.app。我个人最喜欢 CodeKit（仅限 Mac），但 Scout.app 是免费的。
我喜欢关于调查结果“有煽动性”的评论——我个人认为它们很有见地，但它们确实经常引发非常好的讨论，所以安德鲁可能是正确的！
我认为第一张图表在它所属的标题下具有误导性。如果这张图表显示“您首选的 CSS 预处理器”，那么有效的答案要么是您首选的 CSS 预处理器的名称，如果您使用的是小众的，则为“其他”，如果您没有首选的，则为“无”。
通过将“无偏好”、“从未使用”和“不喜欢”分开，你可以得出错误的结论。你将问题改为“你是否使用过预处理器”，并用“大多数人使用过”来回答。
还值得注意的是，在你的结果中，你会期望你的读者对 CSS 预处理器有偏见，因为你已经告诉他们了，例如“在这个预处理的新世界里，没有什么可怕的”。
尽管如此，我并不反对 CSS 预处理器，它们甚至可能对将这些特性引入原生 CSS 产生最佳效果，这将非常棒。
我很想知道那些“不使用”的人在工作类型方面有什么区别。
对我来说，我是一个“小人物”，通常不在本地工作。我参与的网站几乎总是少于 20 个页面，通常接近 8 个左右。我阅读了最近的预处理器文章，但鉴于我的网站规模，仍然没有看到学习它们的任何好处。
我不介意承认我很大程度上是 Dreamweaver 用户。如果我想用（PHP、JS 和所有其他东西）完全在记事本中构建一个网站，但我可以在 Dreamweaver 中快速开发，并使用 GUI 布局完成 80% 的 CSS，其余部分手动调整。
我不断阅读类似上面一位之前发帖者所说的话，“选择一个并开始使用，它将节省你的工作流程数小时，无论选择哪个都没关系，你可以轻松更改……只需尝试一下。”
但老实说，鉴于我的工作类型以及我在 Dreamweaver 中完成工作的速度，我认为情况并非如此……或者至少我还没有看到令人信服的反驳论点。
我只是想知道有多少“不使用”/“没有偏好”的投票者属于类似的类别？
“我们对 46% 从未尝试过的人知之甚少，但我推测他们可能是这样的人群：‘我不需要这个’、‘我甚至不知道它们’以及像这样的人：‘真正的男人不需要预处理器’。”
我认为你忘记了一个重要的人群。那些还没有开始使用的人。因为他们太忙了，因为他们维护的网站仍然使用旧方法，或者因为他们认为这是一个重大的转变。
我属于这一组人，我完全了解预处理器，但还没有使用它们。直到我尝试将 SASS/Compass 与 Scout 结合使用。我花了大约一个小时就完成了切换，并且以后每个项目都离不开它了。
对预处理器一无所知或忽略它们的人应该看看这个
视频 http://www.youtube.com/watch?v=FlW2vvl0yvo&list=HL1339547552&feature=mh_lolz
了解一下它是什么。
我真的不明白使用这些预处理器的意义。学习更多语法以及为了做一些可以在简单的文本编辑器中完成的事情而安装额外的软件，这似乎毫无意义。为什么 CSS 需要变量——只需搜索和替换即可。为什么 CSS 需要速记——只需设置你自己的自定义代码段、键盘快捷键或宏即可。我认为预处理器无法为我做任何事情，而这些事情不能在 vim 中同样快速地完成。但也许我错了，因为我只用 Bootstrap 简单地使用过 LESS。
我自己也问过同样的问题！我们为什么需要这个？搜索和替换很方便，但与一些 sass（或 less）功能相比，它非常有限。
我个人在 sass 中比较喜欢的一些功能
COLOR
EXTEND
假设你有一个名为 .cf 的 clearfix hack。通常，你会将其添加到你的 html 标签中以清除浮动，使用 sass 你可以这样做
这会编译成
……还有很多其他功能。
@Randy
对于一个小网站（登陆页面、单页销售信等），我同意你的观点。
但是对于大型项目或长期发展的项目，CSS 代码管理会变得很痛苦。
预处理器有助于维护代码并节省时间（时间=金钱）
我想我可能比较独特，因为我喜欢省略那些需要我的标记在显示给最终用户之前由外部工具进行处理的步骤。最后，与使用 Linux 自带的标准命令行文本处理工具可以实现的功能相比，我并没有看到它能节省任何时间。在我看来，我所看到的几乎所有标记与它如何编译成 CSS 的示例中，编译后的 CSS 都更容易维护，并且不再需要输入，尤其是我在 vim 中使用了一套自定义的 html5 和 css3 代码段。我认为它们是很棒的替代方案，但目前还没有比旧方法更好。这些处理器的主要好处似乎是 CSS 会被压缩，但已经存在其他工具可以做到这一点。实际上，这完全取决于你的个人工作流程，每个人都至少尝试一下这些工具可能是一个好主意。我使用 LESS 构建了一个网站，并且正在尝试将其用于另一个网站，但仍然没有看到任何真正的节约时间的效果。
你能告诉我，如何使用你提到的宏、代码段或命令行工具来实现我提到的内容吗？我有点困惑……
@Balazs
我根本没有说我的工作流程可以完成 LESS 或 SASS 可以完成的所有事情，只是它提供的一些额外功能对我来说并不值得。你的颜色示例，我无法做到，因为 vim 无法通过调整百分比来选择十六进制颜色（或者也许它可以通过脚本做到），但这还不足以让我信服。另一个示例似乎并没有节省任何输入，并且在后处理格式中似乎更容易维护组织结构。我想优势在于你可以将所有内容都保存在样式表中，但它会被编译成一个加载速度更快的最终结果？此外，这里的大多数人可能都在使用 Mac，所以我无法使用像 CodeKit 这样的工具，因为 CodeKit 可能会让所有这些功能更具吸引力，就像我所看到的 Chris 的入门 SASS 视频演示一样。我仍在尝试使用预处理器，并且刚刚为我的 .less 文件设置了一个脚本，以便在网站自动上传到我的服务器之前，每晚自动编译一次，这样可以为我节省一些额外的工作！
当然不是专家，但在我发现 SASS 非常有帮助的一个例子是，当有一系列元素的尺寸或其他属性相对于某个预先确定的尺寸（例如页面或列宽）时。你可以将该尺寸指定为变量（从技术上讲，它是一个常量，而不是变量），然后对其执行数学运算以计算子节点的尺寸。如果尺寸发生变化，它不仅有用，而且在输入样式时不必在脑海中进行这些计算也很方便。
此外，还有“lighten”和“darken”命令，可用于在主颜色周围创建渐变背景。你可以为该主颜色创建一个变量，并让 SASS 计算比它浅 5% 和深 5% 的阴影用于你的渐变。然后，如果颜色发生变化，渐变也会自动发生变化。我无法在脑海中计算出这些颜色的 RGB 值应该是什么，SASS 为我完成了这项工作。
也许这取决于你习惯了什么。作为一个程序员，然后才是 Web 开发人员，我发现尽可能少地硬编码以及仅对变量和常量进行计算以确定相对的事物是自然而然的。希望这说得通。
@DarrenM：我在这里是 SASS/Compass 的忠实粉丝，起初我对此持怀疑态度。所以，我同意，很难向那些从未尝试过它的人解释 SASS/Compass 有多么强大。
话虽如此，我只是想指出，相对颜色也可以在一定程度上不用 SASS 来实现。你可以定义一个 basecolor，并且为了创建你的“相对”渐变，你可以使用 RGBA 来使阴影、渐变或任何东西变浅或变暗。为了变暗 (rgba(0,0,0,.5))，为了变浅 rgba(255,255,255,.5)，其中 .5 是强度。
尽管如此，这仍然无法与 SASS 中可以对颜色执行的其他操作相提并论。
我长期以来一直有同样的感觉，但现在我不会在没有 Sass/Compass 的情况下构建任何网站（无论大小）。我发现对我的工作流程有很大帮助的功能包括
– CSS3 混合（自动生成所有前缀），
– IE 滤镜回退（< IE9）和 SVG 渐变回退（IE9）用于渐变
– 使用简单的函数调用将 CSS 中的内联图像作为 base64 字符串
– 缓存清除 css 图像
– 一个名为 rgbapng 的 compass 插件，当你传入一个 rgba 值时，它会自动生成一个 1x1px 不透明图像，该图像的颜色与你的颜色相同，并将其内联到你的 CSS 中，以供不理解 RGBA 的浏览器使用。
– 传递十六进制值而不是 RGB 以获得 RGBA 值，例如 rgba(#123456, 0.5)
– 基于 Robert Penner 缓动方程生成 CSS3 立方贝塞尔曲线过渡的 Ceaser 混合。
– 精灵图真是太棒了！！！！
投票给 SaSS
大家，真的试一试吧！我以前也犹豫要不要尝试，但一旦你开始使用它，你就不会想再回到以前了。
我喜欢 SASS/Compass 和 Susy 网格系统，它消除了构建响应式网站的痛苦，并使代码更易于阅读和维护。
你始终可以查看生成的 CSS，你应该这样做，如果你不喜欢看到的内容，可以返回并调整你的 SCSS 或你正在使用的任何语法，这就是你学习的方式。这并不是一项巨大的时间投入，它会很快变得自然，相信我。
做一个周末项目来试一试。
感谢发布这篇文章。在我看来，我的投票投给了 SCSS
我投了“从未尝试过”的票，但在“SASS vs. LESS”文章之后，我在最新的项目中使用了 Stylus + nib :)
一直使用LESS，并使用Codekit作为我的预处理器。
我刚开始使用Sass，我不知道为什么我以前没有使用它。我已经将我的工作流程与LiveReload和Bourbon Sass mixins和工具库结合起来，我感到震惊。任何说它工作量更大的人要么1）害怕学习新东西；要么2）只是单纯的懒惰。如果这些预处理器能做一件事情，那就是让你的生活更轻松。
厌倦了编写一堆重复的垃圾代码？在Sass中嵌套内容。讨厌旧的查找+替换方法？使用变量。想要重用你在不同元素上使用的代码？使用@extend。甚至还能帮你做数学运算。我使用Bourbon包含的flex-grid功能构建了一个响应式布局，并且能够在几个小时内构建一个多列、完全响应式的布局。没有涉及其他框架。我的所有样式都分到各自的样式表中，然后在保存时自动编译成一个文件，通过LiveReload。最重要的是，只要监视文件夹中的文件发生更改，LiveReload就会自动刷新我的浏览器。
怎么会有人不喜欢这个工作流程呢？它非常简单，完全无需手动操作。仅仅Sass就改变了我的整个工作流程。你保存的所有那些代码片段？是的，把那些都扔掉，并构建一个每次都引用的基础SCSS文件。你可以将每个代码片段变成一个@mixin，将其插入到你的基础SCSS文件中，将该文件包含到你的主SCSS文件中，然后随时使用你的代码片段。无需复制粘贴。
这是显而易见的。就像Sass网站上说的，“Sass让CSS再次变得有趣”。
我之前只使用过LESS，但在阅读了所有这些内容后，我想是时候离开我的舒适区，研究一下SASS了。
曾经是“真正的男人不需要预处理器”那一类人，直到我最终想，“好吧，那就试试吧，不会有坏处的。”
显然，我很快就接受了它（SASS）——十分钟内我就想，“这就是我一直以来编写CSS时所期望的！”
感谢SASS的创造者们将我们对CSS的模糊不满变成了现实。对于其他“真正的男人”，不要让你的自尊心妨碍你——SASS（可能还有LESS）是编写CSS的_正确_方法。
你们可以每年提供这个调查吗？我想看看逐年的结果。