Image placeholder

Sass vs SCSS:哪种语法更好?

Image placeholder
F2EX 2017-08-17

自11年前(2006年) Sass 创立以来,一直受到许多争议。它被称为“更好的 CSS ”,并添加了 CSS 作者前所未闻的全新功能,如变量,嵌套和混合。Sass 还诠释了一个完全不同的缩进语法和全新的角度来编写 CSS 。

Sass 语法

Sass 的缩进语法是从其第一个出生的兄弟 Haml 继承而来的。而 Sass 和 Haml 曾经相处的很好 – 嘿,他们甚至分享了相同的 Ruby Gem ! – 然而这个家庭中的一些分歧导致两种语言分裂,最后分开。因为每个人都在寻求自己在开源之地的名利和财富机会。

批评者中的一个常见的异议是, 缩进的语法对 CSS 来说是如此的陌生。为什么要花时间学习与 CSS 截然不同的语言呢?这种差异令他们担心, 使得他们很难继续保持流利的语言与编写细微差别和微妙的 CSS 。如果它只是一时兴起呢?如果不是持续的呢?如果它不能获得大家的认可呢?如果所有的代码和新形成的最佳做法都半途而废了, 如果 “失败” 成为现实呢?如果…

SCSS 来拯救!

在 Sass 的第3版中,SCSS(Sassy CSS)语法被引入为 Sass 的“新主要语法”,并基于 CSS 的现有语法构建。它像 CSS 一样使用括号和分号。它不关心缩进级别或空格。事实上,Sass 的 SCSS 语法是 CSS 的超集 – 这意味着 SCSS 包含 CSS 的所有功能,但是已经扩展到包括 Sass 的功能。按照外行人士的说法,任何有效的 CSS 都是有效的 SCSS 。最后,SCSS 具有与 Sass 语法完全相同的功能,弃用了一些不好的语法。

对于那些刚接触 Sass 的人来说,他们只需要较少的时间来学习。而对于 Sass 的诋毁者来说,他们也不能再抱怨语法了。就我而言,SCSS 是新的 CSS 。

哪个语法更好?

如果你是 Sass 的老用户,那么你会看到哪种语法更好。过道两旁还有很多好人,有些人喜欢 Sass 原来的语法 – 而其他人喜欢 SCSS 。无论哪种方式,都不需要恐慌或担心,因为 Sass 的缩进语法并没有被绝对弃用!

我甚至不会假装在这场辩论中是不偏不倚的。我自己是 SCSS 的头号粉丝,其实最近才转到 SCSS (作者发表于2011年)。 我曾经是缩进语法的忠实粉丝,但我改变了主意,我写了这篇文章来分享原因。

Sass 的优点

原因1: Sass 语法更简洁

是真的。缩进语法消除了对分号和大括号的依赖。它不要求你使用详细的 @include mixin 你的 mixin 。相反,它使用的 + 操作符让你较少的键入, 使你的代码更简单, 更容易阅读。

原因2: Sass 语法更容易阅读

由于它的缩进规则,很难写出不可读的 Sass 。 Sass 强迫你每次都用同样的方式来写你的代码。它对流程非常严格。在大型团队或在你不是所有代码的唯一作者的情况下,这可能非常有用。它迫使团队进行更严格的编码实践(就像 XHTML 为 HTML 所做的那样),也减少了因为编写不规范而被群殴这种事情的发生。

原因3: Sass 语法不会在意分号

好的,我知道这可能属于 #1 的原因,但我需要单独列出,因为它是我喜欢原始语法的主要原因之一。不仅我不必在每个属性/值的末尾键入分号,而且 Sass 确保我的输出始终具有正确的分号。

SCSS 的优点

原因1: SCSS 更具表现力

不完全是!我知道我上面说过 Sass 更容易阅读,因为它迫使你用缩进的方式写出你的规则和属性,但在 SCSS 中编码了一段时间后,我意识到我真的喜欢把成对的 属性/值 写在同一行。但我也不总是这样写。通常,我以扩展格式写入每行一个 属性/值。但是当我只有一个 属性/值 或两个对象时,压缩语法很有用。我特别喜欢更改悬停状态的字体颜色或向链接添加下划线。

对我来说,SCSS 最终比 Sass 更加逻辑地分组。我可以将 Sass 语法中的几行代码放入 SCSS 中压缩。通常规则是分组的。而当读取代码时,代码使用的代码行数往往表示其重要性。

在 SCSS 中,我可以压缩相当标准的直线写法。当我做一些复杂的事情时,可以展开几行。

原因2: SCSS 鼓励适当的规则嵌套

Sass 的一个巨大优势在于它允许你在选择器中嵌套选择器。这是非常棒的,因为当你更改元素的“名称”时,你只需要在一个位置(外部选择器)中更改它,而不是像在编写 CSS 时需要更改许多地方。

深度嵌套的 Sass 生成了具有真正长选择器的 CSS 。特别是如果你使用高级别的逗号运算符(这可能是嵌套最危险的方面)。这不仅是因为它增加了最终的
CSS 的文件大小,所以在其他规则中太多的特异性可能变得非常难以覆盖。如果你非要这么做,你就等着被团队揍吧~

原因3: SCSS 通过 @extend(继承)鼓励更多的模块化代码

因为嵌套在 SCSS 中更难,我发现自己使用 @extend 更频繁。我倾向于编写一个在抽象或虚拟类名称下方深1-2层的代码,然后由其他选择器扩展。再次,这个“丑陋”的大括号有助于我识别我的代码是否嵌套太深,并强制我编写更多的模块化代码。

哦,如果你不使用 @extend 指令,你真的应该去使用 Sass ! :)

原因4: SCSS 让我编写更好的内联文档
原因5: 现有的 CSS 工具通常与 SCSS 协同工作

我实际上并没有使用很多其他的 CSS 工具,但是大多数编辑器已经对 SCSS 进行了内置的支持。

原因6: 与现有的 CSS 代码库集成要容易得多

在构建网站时,我经常不得不与其他 CSS 代码进行整合。在过去,我经常将一些库的代码转换为 Sass ,并在转换过程中失去了宝贵的时间。

对于一个库,并不需要你去维护代码。当你升级库时,最后一件事就是进行转换过程而已。如果它是一个现有的代码库,那么进行更小的更改通常要好得多,而不是对它进行重构。

SCSS 让你可以使用现有的代码。

原因7: SCSS 提供了更低的门槛

从倡导 Sass 的角度来看,说服某人使用 SCSS 比 Sass 要容易得多。只需要简单介绍几个新概念(SCSS),而不是全新的语法。

原因8: SCSS 可以成为 CSS 的下一个版本

自创立以来,Sass 和类似的语言吸引了很多人的关注。其中一些人已经在考虑给 CSS 添加 Sass 的一些功能。SCSS 中引入的语法可能会变成 CSS4 !

总结:

我希望自己对这两种语法都有自己的看法。虽然我明确地在争论 SCSS 语法的优点。如果你只接触到 SCSS 语法,也许你会尝试花费一些时间去了解 Sass
的语法。而如果你是一个纯粹主义者,你会从 SCSS 语法中受益。

最后讲一个笑话:

猿A:嗨,你用 Sass 吗?
猿B:用啊。
猿A:太好了,让我看看你写的代码。
猿B:好啊(默默打开代码)。
猿A:咦?不太对啊,你这是 SCSS 吧?
猿B:对啊。
猿A:没有使用 Sass 写的代码吗?
猿B:这不就是使用 Sass 的 SCSS 写的么。
猿A:干嘛不用 Sass 啊。
猿B:我用了啊。
猿A:你明明用的 SCSS 啊。
猿B:SCSS 就是 Sass 啊,你只说有没有用 Sass ,又没有说有没有用 Sass 的 Sass 写啊。
猿A:猝

原文:http://thesassway.com/editorial/sass-vs-scss-which-syntax-is-better


2017-09-02