决定反对 HAML/SASS 的一些理由是什么？答案

【问题标题】：What would be some reasons to decide against HAML/SASS?决定反对 HAML/SASS 的一些理由是什么？
【发布时间】：2011-01-14 03:48:01
【问题描述】：

我最近一直在阅读有关 HAML/SASS 的信息，但我不太确定为什么有人不想使用它。它似乎很容易切换，让事情变得更清洁、更高效。

更新：

使用其中一个怎么样？我听到的大多数投诉（少数投诉）似乎是关于 HAML，混合和匹配 XHTML/HAML 和 CSS/SASS 会有什么问题吗？

更新：

抱歉，问题的最后一次更新。在我看来，从 SASS 切换回 CSS 既轻松又简单。从 HAML 切换回 HTML 怎么样？

【问题讨论】：

标签： ruby-on-rails css xhtml haml sass

【解决方案1】：

如果您使用的是 Rails，是的。去吧。但是，您会遇到的一些问题是，以后加入团队的任何其他开发人员也必须学习它。如果您已经在与一大群 Rails 合作，那很好，但 HAML/SASS 可能会让多年来一直使用纯 HTML/CSS 的设计师感到困惑。

但是，如果您不使用 Rails，则很难找到一个好的 HAML/SASS 集成系统。那里有一些，但我想它们没有得到很好的支持或与规范一样远。

但是，是的。 HAML/SASS 绝对值得。您会遇到的唯一真正问题是它还不是标准的。

至于混合搭配，HAML 和 SASS 在风格上非常相似，我会说两者都适合，但它再次归结为个人喜好。尝试使用这两种方法一天，如果您不喜欢其中一种，请切换回来。没有技术问题，所以随你喜欢。

【讨论】：

在我看来几乎没有学习曲线可以转换，所以让使用纯 HTML/CSS 的人学习 HAML/SASS 会是个问题吗？
确实不应该，但是有些顽固的人学不会新方法。这是一个骗局，但这是我唯一能真正想到的。 HAML/SASS 非常棒，如果它最终适合你（或你的团队），那就去吧。它的系统本身没有太多固有缺陷，所以人们似乎是唯一真正的障碍。
HTML/CSS 再简单不过了。您是否真的认为运行 ruby 进程以根据源文件的制表符分隔为您添加结束标签的“唯一真正的问题”是“它还不是标准的”？
@jib：哎呀。不清楚您是在谈论在现有 Rails 进程上增加一点额外负载，还是在更静态的环境中使用--watch 进行转换。在第一种情况下，现在的 HAML 性能现在非常接近 ERB，因此对最终用户的影响可以忽略不计。其次，对于最终用户来说绝对不会影响性能，所以当然我会采用我喜欢的标记样式。我不确定您在谈论 HAML 的其他什么样的不良影响，但性能绝对不是其中之一。只是原则还是什么？

【解决方案2】：

有很多工具可以处理 HTML 和 CSS。语法不是很漂亮，但 HAML 和 SASS 的改进对我来说似乎并不那么引人注目，而且对于许多人来说，它们不值得麻烦。当然，对于那些使用广泛不同的框架（与 Rails 不同）开发 Web 应用程序的人来说，找到一个理由去忍受集成如此陌生的东西的痛苦就更难了。（例如：想解释一下将 SASS 集成到我的 Java/Stripes/JSP 环境中我必须做些什么？:-)

【讨论】：

从 HTML 到 HAML 的区别基本上是表面上的，你说得对。但是，SASS 提供了 CSS 中不存在的功能，例如变量、mixin、算术（用于尺寸和颜色）、循环等等。它真的把 CSS 放在了一个完全不同的层次上。 Sass 的新版本 3 实际上支持两种语法模式，他们现在正在推广 SCSS 语法（一种类似 CSS 的花括号），因为人们被空白感知 SASS 语法所吸引，而没有意识到它还有更多功能而不仅仅是他们可能不喜欢的不同语法。
Sass 不必“集成”到您的环境中。它只生成静态 CSS 文件，因此您可以使用任何方法来调用它。我通常总是在 sass 之上使用 compass（一个样式函数库），它提供了一个 compass watch 命令，用于在保存时自动编译 sass 文件。 [投票给你-1，因为你已经得到了6（！），而且消息不是那么好......没有难过的感觉。 :-)]
@Andrew 通过“集成”我主要是指“集成到构建过程中”，我认为这样的工具在某种程度上必须这样做。它要么成为应用程序构建的一部分，要么成为一个单独的构建。无论哪种方式，它都必须“融入”我的工作方式。例如，“自动编译”工具在我习惯的那种构建环境中完全没用（而且我更喜欢）。问题是征求意见，因此基于您的对我的情况的明显不完整理解来否决我的意见似乎很荒谬。

【解决方案3】：

我参与了一些志愿者项目，其中 HAML 的语法曲线（语法空白、标签的自动生成等）被视为一个障碍：对于刚接触该项目的程序员来说，还有一件事要学习。

就我个人而言，我认为 SASS 是值得的，但我对 HAML 持怀疑态度：在调试 HAML 模板之前，您似乎不必使用 HAML 进行打字，因为您花时间调试为什么您的模板有错误。不过，这可能是（HAML）新手的观点。

【讨论】：

我同意，我发现 HAML 比纯 HTML 更难处理。每次浏览器中出现错误时，您都必须将 HTML 输出映射回原始 HAML ......我只是不明白这样做的好处是什么。新的语法，令人无法容忍和考虑不周的空白，额外的调试层。

【解决方案4】：

我倾向于同意这个问题；它很容易切换，语法也没有那么复杂，而且它确实让事情变得更干净、更高效。这也使得无意中生成无效的 HTML 变得更加困难。

我还认为学习曲线很浅，以至于无法处理它的程序员可能是一个程序员，如果没有你的团队，你会过得更好。这听起来可能很苛刻，但我相信。

我能看到的唯一缺点是，如果您是在 ASP.NET 中进行开发，或者在改造 Haml 和 Sass 会很痛苦的情况下，方式对于使用该平台的其他人来说是出乎意料的，并且在生产环境中维护可能是一件苦差事。不过，在 Rails 上，去吧。

【讨论】：

【解决方案5】：

我认为使用 HAML 不会给项目带来太多好处。

另一方面，SASS 有效地引入了变量和计算以及其他真正有用的功能，从长远来看，这些功能可以为您在大型项目中节省时间和精力。

对于任何比简单的单页表单更大的项目，使用 SASS 都非常聪明。

【讨论】：

【解决方案6】：

我尝试使用 SASS，但发现使用 MacRabitt's CSSEdit（仅限 Mac）编辑 CSS 对我的工作方式来说更容易、更高效。我是一个非常直观的人，并且喜欢在更改样式表时进行实时预览，并且不想将大量时间投入到我没有遇到问题的事情上。

【讨论】：

【解决方案7】：

大多数人没有意识到的一件事是HAML sucks for content。它非常适合结构标记，但不要试图将其推得太远。（您也可以在 HAML 文件中混合和匹配 HTML！）

Sass 绝对不可或缺，尤其是从长远来看。这不仅仅是在你脑子里想的时候编写样式表，而是在以后维护它们。新的 Sass3 将语法问题排除在外：如果您更喜欢花括号 SCSS 语法，您可以自行选择。

【讨论】：

【解决方案8】：

HAML/SASS 使用起来确实很棒，但它们确实引入了技术和知识导向的依赖关系。如果您的开发和生产环境受到足够的控制和可预测，并且新手接受足够的培训（或在进入组织的过程中接受学科知识审查）以开始运行，这可能不是问题，但所有这些都是开销得到承认。

【讨论】：

【解决方案9】：

这是为什么..

%p
  hello world

比这更好..？

<p>hello world</p>

线索.. 如果你不做 ruby，那就不是。不幸的是，添加结束标签和大括号并不是制作网页最具挑战性的方面，因此大多数专业人士不会真正关心。使用您喜欢的任何一个。

【讨论】：

这绝对是个人决定，但 OP 已经确定他更喜欢 HAML/SASS。在这种情况下，“它并没有那么好”不是一个有效的骗局。
它可能会治愈基于尖括号的 RSI。
如何让 OP 同意他的偏好无效？
如果你不想使用 Haml，没关系，你是对的，这是个人选择。但是您显然没有考虑足够的想法来给出明智的答案。我会告诉你为什么 sn-p 可能会更好：因为你选择了 Haml 带来的好处最少的情况，而且它仍然可以节省代码。当我在编辑你的页面时，我必须越过越少的废话越好。这并不是说“添加结束标签”很难——而是它们占用了您文档中的空间而没有任何好处。 Haml 的好处在于可读性。
代码少？是的。增加依赖性？是的。秋千，回旋处？是的。

【解决方案10】：

从开发人员的角度来看，Haml 和 Sass 绝对是摇滚。但是：从设计师的角度来看，Haml 和 Sass 可能不可读。这实际上取决于您团队中的成员。

如果是一群不怕学习 DSL 的开发人员和/或设计师，那么绝对会去。

如果您有一个混合团队，其中设计师将他们的 CSS 和 HTML 工作交给开发人员，开发人员将其翻译成 Haml/Sass，当然可以。

如果您有一个设计团队将工作交给开发人员并将工作流回给设计师，您可能不想要使用它，因为设计师可能无法使用他们的工具来完成编辑文件。

如果您有一个小型团队，营销人员和业务人员需要编辑网页，而他们只知道 HTML 和少量 CSS，那么您可能不应该使用 Haml/Sass。

但是，您不能在这里真正做出笼统的陈述。考虑到至少使用 Rails，您可以在视图中混合模板类型。因此，您的一些模板可以是 .erb 文件中的纯 HTML，而其他页面是 .haml 文件。您可以将一种类型的部分插入到另一种类型的模板中。（我认为混合类型可能是一种不好的做法，但如果您只需要“完成工作”，那么它是一种选择。）

【讨论】：

谢谢，我实际上已经根据您的回答更新了我的问题。从 HAML 切换回 HTML 有多容易？
你的意思是把 HTML 取出来？ Haml 最终以 HTML 形式结束。（您的网络浏览器不知道 Haml 是什么。）您可以只渲染页面，然后在浏览器中查看源代码并复制出您需要的内容。或者，在 Rails 中，只需将模板渲染回字符串并将其保存到文件中...如果您正在考虑转换 Haml -> Erb，嗯，我不知道任何实用程序。

【解决方案11】：

我现在在一个 Django 项目上使用 SASS。我喜欢它，并将继续使用它。然而，我发现的一个问题是错误消息并不总是特别直观，尤其是如果您省略了}。

【讨论】：