决定不使用HAML/SASS的原因有哪些？

Question

决定不使用HAML/SASS的原因有哪些？

ruby-on-railscssxhtmlhamlsass

16

最近我一直在研究HAML/SASS，但我不太确定为什么会有人不想使用它。它似乎很容易切换，使事情更加整洁高效。

更新：选择其中一个怎么样？我听到的大部分抱怨（虽然抱怨很少）似乎都是关于HAML的，混用XHTML/HAML和CSS/SASS会有任何问题吗？

更新：对不起，最后一个问题，从SASS切换回CSS似乎是轻松简单的，但是从HAML切换回HTML呢？

- GiH

11个回答

6

有许多用于处理HTML和CSS的工具。虽然语法不太好看，但对我来说，HAML和SASS的改进似乎并没有那么显著，而且对于许多人来说，它们也不值得费那个劲。当然，对于那些使用与Rails大相径庭的框架开发Web应用程序的人来说，要去整合一些完全陌生的东西就更难了。（例如：有没有兴趣解释一下我必须怎样将SASS集成到我的Java/Stripes/JSP环境中？:-)）

- Pointy

1

从HTML到HAML的区别基本上只是外观上的，你说得对。然而，SASS提供了CSS中不存在的功能，例如变量、mixin、算术（用于尺寸和颜色）、循环等等。它真正将CSS提升到了一个全新的水平。Sass的新版本3实际上支持两种语法模式，他们现在正在推广SCSS语法（类似于CSS的带大括号的语法），因为人们被空格感知的SASS语法所困扰，并没有意识到其中还有更多内容，而不仅仅是一种他们可能不喜欢的不同语法。 - Andrew Vit

Sass不需要“集成”到您的环境中。它只生成静态CSS文件，因此您可以使用任何方法来调用它。我通常总是在sass之上使用compass（一组样式函数库），它提供了一个compass watch命令，可在保存时自动编译sass文件。[给你投了-1票，因为你已经得到了6票（！），而且并不是那么了解情况...没有恶意。:-)] - Andrew Vit

2

@Andrew，我所说的“整合”主要是指“整合到构建过程中”，我认为这样的工具在某种程度上必须这样做。它要么成为应用程序构建的一部分，要么成为一个单独的构建。无论哪种方式，它都必须“整合”到我的工作方式中。例如，“自动编译”工具在我习惯的构建环境（也是我喜欢的）中将完全无用。问题正在征求意见，因此基于您明显不完整的对我的情况的理解而对我的意见进行投票似乎是荒谬的。 - Pointy

5

我曾参与志愿项目，其中HAML的语法曲线（语法空格，自动生成标签等）被视为一种障碍：对于新加入项目的程序员来说，这是需要学习的又一件事情。

就我个人而言，我认为SASS是值得的，但对于HAML，我还没有下定论：在调试HAML模板之前，似乎你不需要输入的内容反而被花费在了解决模板中出现的错误上。不过这可能是一个（HAML）新手的看法。

- RyanWilcox

5

我同意，相较于纯HTML，我觉得HAML更难处理。每当浏览器出现错误时，你必须将HTML输出结果映射回原始的HAML...我不明白其所谓的好处是什么。新语法、难以忍受和思考不周的空格、额外的调试层。 - Toby Hede

3

我倾向于赞同这个问题; 它很容易切换，语法并不复杂，而且它可以使事情更加清晰和高效。它还可以使生成无效HTML的可能性变小。

我认为学习曲线足够浅，以至于一个无法掌握它的程序员可能是你团队中不需要的程序员。这听起来可能有些苛刻，但我相信这一点。

我唯一能看到的缺点是，如果您正在使用ASP.NET或其他一些平台，在后期添加Haml和Sass将会很麻烦，并且对于其他平台的用户来说，这是非常意外的，并且在生产环境中可能会很繁琐。但是在Rails上，可以尝试使用它。

- Jakob Borg

2

我认为在项目中使用HAML并没有太多好处。

另一方面，SASS有效地引入了变量、计算和其他非常有用的功能，在更大的项目中节省时间和精力。

对于任何大于简单单页表单的项目，使用SASS都是非常明智的选择。

- CPrimer

2

我尝试使用SASS，但发现使用MacRabitt's CSSEdit（仅适用于Mac）编辑CSS更容易且更符合我的工作方式。我是一个非常视觉化的人，在修改样式表时喜欢有实时预览，并且不想花费大量时间去学习一些我并没有问题的东西。

- Peter Brown

2

很多人没有意识到的一件事是，HAML不适合用于内容。它非常适合结构性标记，但不要试图过度使用它。（您也可以在HAML文件中混合和匹配HTML！）

Sass是绝对必不可少的，尤其是从长远来看。这不仅仅是关于当你已经有了所有样式表并且在头脑中完全掌握它们时编写它们，而是关于在日后维护它们。新的Sass3消除了语法问题：如果您喜欢花括号SCSS语法，您可以随意选择。

- Andrew Vit

1

为什么会这样..

%p
  hello world

比这个更好的方案吗？

<p>hello world</p>

提示.. 如果你不使用 Ruby，那么这并不重要。不幸的是，添加闭合标签和大括号并不是制作网页最具挑战性的方面，因此大多数专业人士并不会太在意。使用任何你喜欢的方式。

- unknown

这绝对是个人决定，但OP已经确定他更喜欢HAML/SASS。在这种情况下，“它并不真的更好”不是一个有效的反对理由。 - Matchu

1

它可能会治疗基于尖括号的 RSI。 - Rich Bradshaw

如果你不想使用Haml，那没问题，毕竟这是个人选择。但你显然没有考虑得够充分，无法给出一个明智的答案。我告诉你为什么那段代码可能更好：因为你选择了Haml效果最小的情况，它仍然可以节省代码。当我编辑你的页面时，我需要浏览的垃圾越少越好。这不是因为“添加闭合标签”很难——而是因为它们占据了文档中的空间，没有任何好处。Haml的好处在于可读性。 - Chuck

少代码？是的。增加依赖？是的。得失并存？是的。 - unknown

如果你曾经考虑过，我认为你应该表达出你的真实观点，解释为什么Haml不够可读，而不是像它的存在理由是为了帮助人们省去输入关闭标签的麻烦。我的问题不在于你对Haml的否定态度，而在于你的回答完全歪曲了某些人使用Haml的原因。 - Chuck

显示剩余2条评论

1

HAML/SASS 可能确实很棒，但它们会引入技术和知识方面的依赖关系。如果您的开发和生产环境足够受控和可预测，并且新手接受了足够的培训（或在进入组织时经过了主题知识的审核），以便立即开始工作，那么这可能不是问题，但所有这些都是需要承认的额外开销。

- Eric

0

从开发人员的角度来看，Haml和Sass绝对是非常好的。但是：从设计师的角度来看，Haml和Sass可能不太容易阅读。这真的取决于你的团队成员。

如果你的团队成员都是开发人员和/或设计师，并且不怕学习DSL，那么绝对可以使用。

如果你的团队是混合团队，其中设计师将他们的CSS和HTML工作交给开发人员来翻译成Haml/Sass，那么当然可以使用。

如果你的设计团队将工作交给开发人员，而工作又流回到设计师手中，那么你可能不想使用它，因为设计师可能无法使用他们的工具编辑文件。

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

然而在这里你不能真正地做出一概而论的陈述。请考虑至少在Rails中，您可以在视图中混合模板类型。因此，您的某些模板可以是纯HTML，存储在.erb文件中，而其他页面则是.haml文件。您可以将部分内容作为一种类型插入到另一种类型的模板中。（我认为混合使用不同类型可能是一个不好的实践，但如果您只需要“完成工作”，那么这是一个选项。）

- Amy

谢谢，实际上在看了您的回答后我已经更新了我的问题。从HAML切换回HTML有多容易？ - GiH

1

你的意思是只是将HTML取回来吗？ Haml最终会变成HTML。（您的Web浏览器不知道Haml是什么。）您可以直接呈现页面，然后在浏览器中执行“查看源代码”并复制所需内容。或者，在Rails中，只需将模板呈现回字符串并将其保存到文件中...如果您想将Haml-> Erb转换，那么我不知道有任何实用程序。 - Amy

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Matchu · Accepted Answer

如果你正在使用Rails，那么肯定可以使用。不过需要注意的是，后来可能加入团队的任何其他开发人员也必须学习使用HAML/SASS。如果你已经在与大量Rails开发人员合作，那就没问题了，但是对于多年使用纯HTML/CSS的设计师来说，HAML/SASS可能会让他们感到困惑。

如果你没有使用Rails，那么很难找到一个好的集成了HAML/SASS的系统。虽然有一些这样的系统，但我想它们的支持可能不够好或者还没有完全符合规范。

但是，HAML/SASS绝对值得一试。唯一真正的问题是它尚未成为标准。

至于混合使用，HAML和SASS的风格非常相似，所以我认为两者都可以使用，但又取决于个人喜好。试用一天两种工具，如果你不喜欢其中的一种，就切换回另一种。从技术上讲没有问题，所以按照自己的喜好去做吧。