值得学习haml & 吗？粗鲁？
在您的职业经验中，有haml & sass 被证明有用吗？通过什么方式？
In your professional experience have haml & sass proved to be useful? In which way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
Haml 很好，我经常使用它，但单独使用 Sass 就值得了，特别是当您必须构建复杂的样式表时。例如，CSS 最糟糕的事情之一是命名选择器时必须做很多冗余。在CSS中，你必须
使用Sass，你可以简单地自然地嵌套这些后代。
您还可以使用变量
并且您可以使用它们进行数学计算
您还可以共享代码
这其中的力量如此之大，您应该自己去学习它。另外，最终结果是纯 CSS，因此可以进行转换。
不要忘记 css2sass 它将现有的 css 转换为 sass 文件！
如果您愿意，可以在 http://rendera.heroku.com/ 上玩一些示例。这是我建立的一个网站，旨在帮助人们学习 HTML5 和 CSS3，并且我在那里支持 HAML 和 SASS。
另外，请查看 StaticMatic (staticmatic.rubyforge.org)，了解使用 HAML 和 SASS 进行静态网站工作的惊人方法。它生成可以上传到静态主机的网站，并具有类似于 Ruby on Rails 的布局和模板系统。
为了解决您提出的直接问题，通过“值得吗”的方式，答案是肯定的。能够使用变量、通过选择器轻松分组以及通过模块共享代码使复杂的样式表变得更加容易。构建样式表根本不需要很长时间，您可以使用优秀的 Compass 框架走得更远。例如，您可以使用 960.gs 或 Blueprint 模块将这些框架混合到现有样式表中。这样您就不必更改代码的标记。将 960.gs 及其“grid_12”和“container_12”类添加到所有标记中可能是不可能的，但使用 Compass 和 Sass 则轻而易举。
Sass 还可以更轻松地为开发模式使用多个样式表并生成用于生产的单个样式表，从而提高客户端性能（页面加载时对服务器的调用更少）。HAML
有其自身的优点，尽管它们并不那么明显作为萨斯。 HAML 确实使嵌套元素和声明 DIVS 变得异常简单...例如，使用 HAML 甚至使用常规 960.gs 也很容易：
更少的打字。如果您决定出于某种原因需要为所有这些内容添加包装器，只需将整个内容缩进新标签下方即可。
希望有帮助。 I＜3Sass。
Haml is nice, and I use it a lot, but Sass is worth it alone, especially if you have to build complex stylesheets. For example, one of the worst things about CSS is how much redundancy you have to do when naming selectors. In CSS, you have to do
With Sass, you can simply nest these decendants naturally.
You can also use variables
And you can use math with them
You can also share code
There's so much power in this that you owe it to yourself to learn it. Plus, the end result is plain CSS so it can be converted.
Don't forget about css2sass which converts your existing css to sass files!
You can play with some examples at http://rendera.heroku.com/ if you'd like. It's a site I built to help people learn HTML5 and CSS3 and I have support for both HAML and SASS there.
Also, take a look at StaticMatic (staticmatic.rubyforge.org) for an amazing way to do static web site work with HAML and SASS. It generates web sites you can upload to static hosts and has a layout and template system similar to Ruby on Rails.
To address the direct question you asked, by way of "is it worth it", the answer is yes. Being able to use variables, easily group things by selector, and share code via modules makes complex stylesheets much easier. Building the stylesheets doesn't take long at all, and you can use the excellent Compass framework to go even further. For example, you can use the 960.gs or Blueprint modules to mix those frameworks into your existing stylesheets. This way you don't have to change the markup of your code. Adding 960.gs and its "grid_12" and "container_12" classes to all of your markup might not be possible, but with Compass and Sass it's a breeze.
Sass also makes it easier to have multiple stylesheets for development mode and generate a single stylesheet for production, thus improving client-side performance (less calls to the server on page load.)
HAML has its own benefits, although they're not as noticeable as Sass. HAML does make it incredibly easy to nest elements and declare DIVS... using even regular 960.gs for example is easy with HAML:
Much less typing. And if you decide you need to add a wrapper around all of that for some reason, just indent the whole thing beneath a new tag.
Hope that helps. I <3 Sass.
我当前的网站有超过 800 个 Haml 文件和 150 个 Sass 文件，让我告诉你，它对我的发展有很大帮助。
最大的好处是快速开发：创建 Haml/Sass 文件需要的打字量要少得多，因此与制作 erb 模板相比，您可以用更少的击键来确定表示逻辑。
我还发现 Haml 文件更容易阅读，并且不易出错。
YMMV，但我已经到了不使用 Haml 感觉就像一件苦差事的地步。
My current web site has over 800 Haml files and 150 Sass files, and let me tell you it has helped my development tremendously.
The biggest boon is in terms of rapid development: creating Haml/Sass files requires far less typing, so you can nail out your presentation logic with far fewer keystrokes than if you were doing an erb template.
I also find Haml files far easier to read, and less error prone.
YMMV, but I have reached the point that not using Haml feels like a chore.
TL;DR - 虽然很流行，但我不喜欢使用 HAML 或 SASS，但我喜欢 SCSS。
似乎对 HAML 的普遍共识是压倒性地支持它，但我个人并不关心它。
如果我的目的是生成 HTML，那么我更喜欢模板语言尽可能接近 HTML。这避免了必须学习另一层间接性，这会增加混乱和错误的机会以及产生认知开销。
我发现 HAML 对我首选使用空格以提高可读性和换行的限制非常繁重，并且通常会导致语法难以阅读。
最近，我在 HAML 模板中遇到了一个微妙的错误，如果模板是 ERB，则该错误会立即显而易见，例如：
表行不在 THEAD 标记内，这是完全有效的 HAML，但不正确相对于预期的 HTML 结构。虽然页面看起来可以正确呈现，但 CSS 选择器失败，导致某些 Javascript 代码出现无提示故障。
我确信这种错误对于大多数 HAML 用户来说是显而易见的，如单独所示，但在较大模板的上下文中，可能很难发现；特别是对于刚接触 HAML 的开发人员来说。
另一方面，如果这是 ERB 或 HTML：
在我看来，由于 ERB 和 HTML 几乎总是缩进的方式，结构中的错误更容易被发现。
我花了近二十年的时间编写 HTML，我必须承认，我对编写格式良好的 HTML 感到非常自豪，并且我认为没有理由学习不同的表示它的方式以及学习发现错误所需的所有新视觉模式。
另一方面，我非常喜欢 SCSS（而不是 SASS），因为 SCSS 本质上是 CSS 的超集。它没有添加我需要在心里翻译的全新间接层。它仅在语法上添加了适度的更改，从而提供了更简洁（且干练）的 CSS 表示形式，我发现它非常易于阅读和理解。
事实上，我不喜欢使用任何对如何缩进或换行代码执行严格语法的语言，例如 python。或者仅充当底层语言（例如咖啡脚本）之上的间接层的语言。
我并不是说我相信抽象和间接在编程语言中是不好的；而是说我认为抽象和间接在编程语言中是不好的。只是我不想在此处讨论的特定语言中使用它们。
TL;DR - While popular, I prefer not to use HAML or SASS, but I like SCSS.
It seems that the general consensus on HAML is overwhelmingly in favor of it, but personally I do not care for it.
If my intention is to generate HTML, then I prefer the template language to be as close HTML as possible. This avoids having to learn another layer of indirection which adds opportunity for confusion and error as well as incurring cognitive overhead.
I find the constraints that HAML places on my preferred use of whitespace for readability and line wrapping to be onerous and often results in a syntax that can be difficult to read.
Recently I encountered a subtle error in a HAML template that would have been immediately obvious if the template were ERB, for example:
The table rows are not within the THEAD tag, which is perfectly valid HAML, but incorrect with respect to the intended HTML structure. While the page appeared to render properly, a CSS selector failed, which resulted in a silent failure of some Javascript code.
I'm sure this kind of error would be obvious to most HAML users, as shown in isolation, but in the context of a larger template, it can be hard to spot; especially to a developer new to HAML.
On the other hand, if this were ERB or HTML:
To my eye, the error in structure is much easier to spot due to the way ERB and HTML are nearly always indented.
Having spent nearly two decades writing HTML, I must admit that I have a certain pride in writing well formed HTML and I see no reason to learn a different way of representing it and learning all of the new visual patterns needed to spot errors.
On the other hand, I very much like SCSS (as opposed to SASS) because SCSS is essentially a superset of CSS. It does not add a completely new layer of indirection that I need to mentally translate. It adds only a modest change in syntax which provides a more concise (and DRY) representation of CSS which I find very easy to read and understand.
Indeed, I prefer not use to any language that enforces a strict syntax regarding how I should indent or line wrap my code such as python. Or languages that serve only as an indirection layer on top of an underlying language such as coffeescript.
I'm not saying that I believe abstraction and indirection are bad in programming languages; only that I prefer not to use them with respect to the specific languages discussed here.