决定反对HAML / SASS的原因有哪些？

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

为什么是这样..

%p
  hello world

比这更好..？

<p>hello world</p>

线索..如果您不是在做红宝石，那不是。不幸的是，添加结束标记和花括号并不是制作网页中最具挑战性的方面，因此大多数专业人士并不在意。使用任何您喜欢的。

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

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

如果您有一个混合团队，那么设计师可以将他们的CSS和HTML投给将其转换为Haml / Sass的开发人员。

如果您有一个设计团队将工作传递给开发人员，而工作又流回设计人员，则您可能不希望使用此功能，因为设计人员可能无法使用其工具来编辑文件。

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

但是，您实际上不能在这里做一个笼统的声明。考虑到至少使用Rails可以在视图中混合模板类型。因此，您的某些模板可以是粘贴在.erb文件中的纯HTML格式，而其他页面则是.haml文件。您可以将一种类型的局部变量插入另一种的模板中。（我认为混合类型可能不是一个好习惯，但是如果您只需要“完成工作”，则可以选择）。

HAML / SASS的使用确实确实很棒，但是它们确实引入了技术和知识导向的依赖关系。如果您的开发环境和产品环境受到足够的控制和可预测，并且新手要接受足够的培训（或者经过培训以获取进入组织的主题知识）来投入运营，那么这可能不是问题，但是所有这些都是开销被承认。

大多数人没有意识到的一件事是HAML很吸引内容。这对于结构化标记非常有用，但不要尝试将其推得太远。（您也可以在HAML文件中混合并匹配HTML！）

Sass绝对不可或缺，特别是从长远来看。当您掌握所有内容时，这不仅涉及编写样式表，而且还涉及维护样式表。新的Sass3消除了语法问题：如果您喜欢花括号的SCSS语法，则可以选择。

我倾向于同意这个问题。它很容易切换，语法不是那么复杂，并且确实使事情更整洁，更高效。这也使得更难以无意间生成无效的HTML。

我还认为学习曲线很浅，以至于无法处理的程序员可能是一个没有团队就可以更好的程序员。这听起来很刺耳，但我相信。

唯一的缺点，我可以看到是，如果你在ASP.NET开发或一些地方改造Haml的和无礼的话将是一个痛苦，是这样意外的其他任何人使用这个平台，和可能的苦差事在生产环境中维护。不过，在Rails上，继续努力吧。

我尝试使用SASS，但发现使用MacRabitt的CSSEdit（仅限Mac）编辑CSS 对于我的工作方式来说更轻松，更高效。我是一个非常有远见的人，喜欢在更改样式表时进行实时预览，并且不想在我没有问题的事情上花费大量时间。

有很多使用HTML和CSS的工具。语法不是很漂亮，但是HAML和SASS的改进对我来说似乎并不那么引人注目，对于许多人来说，这样做是不值得的。当然，对于那些使用广泛不同的框架（与Rails不同）开发Web应用程序的人来说，更难找到理由去集成如此陌生的东西。（示例：请注意解释将SASS集成到Java / Stripes / JSP环境中需要做什么？:-)

我参与过一些志愿项目，在这些项目中，HAML的语法曲线（语法空白，标签的自动生成等）被视为障碍：对于项目新手来说，程序员需要学习的另一件事。

就个人而言，我认为SASS是值得的，但我对HAML持怀疑态度：在调试之前，已经调试了HAML模板，好像您不必使用HAML进行的键入已被您花费在调试上的时间所克服了，为什么会有一个模板上的错误。不过，这可能是（HAML）新手的观点。

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

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

对于任何不仅仅是一个简单的一页表单的项目，使用SASS都非常聪明。