对于潜在的高流量网站，我应该使用 haml 或 erb 或 erubis 吗？
我最近一直在玩 Haml，非常喜欢最终代码对我来说的样子……开发人员。 我也不太担心设计师能够使用或改变它......我们是一个小团队。
也就是说，开始一个我们相信会产生大量流量的项目（谁不会呢？）。 我担心有些事情我不了解 haml。 有什么是 erb 能做而 haml 不能做的吗？ 随着项目的发展，haml 会产生负面影响吗？ 还有其他需要考虑的事情吗？
最后...Haml 的速度与 erubis 相比如何？ 我发现它现在据说击败了 erb 和 eruby...
谢谢！
I have been playing with Haml recently and really like the way the resulting code looks to me...the developer. I'm also not too worried about a designer being able to consume or change it...we're a small team.
That said, beginning work on a project we believe will generate quite a bit of traffic (who doesn't?). I'm concerned that there are things I just don't know about haml. Is there anything erb can do that haml can't? Does haml have a negative effect as a project grows? Are there other things that should be considered?
And finally...how does Haml compare speedwise to erubis? I see that it supposedly beats erb and eruby now...
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
哈姆尔摇滚。 我没有看到任何最近的性能数据，但这些天已经非常接近 erb 了。 我认为如果你打开丑陋模式（这可以防止漂亮的缩进），它可能会比 erb 更快。我们每天使用 Haml 进行 280 万次综合浏览。
Haml 源代码树中有一个基准测试程序：
http://github.com/nex3/haml/tree/master/test
2009 年 11 月更新
Nathan（Haml 的主要开发人员）在他的博客上发布了一些 Haml 2.2 基准测试。 您可以在那里看到确切的数字，但简而言之：
您可以通过放置 Haml::Template 来启用丑陋模式： :options[:ugly] = true 在初始化程序或环境文件中。 请注意，丑陋模式并不是真的那么丑陋 - 生成的 HTML 实际上比 ERB 漂亮得多 - 它只是缩进得不好。
Haml rocks. I haven't seen any recent performance numbers but it is pretty close to erb these days. I think that it might be faster than erb if you turn on ugly mode (which prevents the pretty indentation) We're doing 2.8 million pageviews a day with Haml.
There is a benchmarker checked into the Haml source tree:
http://github.com/nex3/haml/tree/master/test
Update November 2009
Nathan (Haml's main developer) published some Haml 2.2 benchmarks on his blog. You can see the exact numbers there but in short:
You can enable ugly mode by placing
Haml::Template::options[:ugly] = truein an initializer or environment file. Note that ugly mode isn't really that ugly - the resulting HTML is actually much prettier than ERB - it's just not indented nicely.如果您使用 Rails，Haml 和 erubis 之间的性能差异可以忽略不计：无论如何，模板在第一次命中后就会被编译和缓存。 将此与片段和页面缓存结合起来，您可以放心，视图不是应用程序的性能瓶颈。
你应该问自己的问题是：你喜欢写 Haml 吗？ 它能让你更有效率吗？ 然后你就可以更容易地做出决定。
If you use Rails, the performance difference between Haml and erubis is negligible: templates get compiled and cached after the first hit, anyway. Combine this with fragment and page caching and you can rest assured that views are not the performance bottleneck of your application.
The question you should be asking yourself is: do you like writing Haml? Does it make you more productive? Then you can decide easier.
我喜欢 HAML，因为它是一个可以轻松编写结构化 HTML 的好工具，而且通常使用起来很愉快。 但这与根据网站可能拥有的流量来选择工具几乎没有关系。
如果您担心流量，则应该担心是否正确使用缓存。 然后您需要应用一般 Web 应用程序性能的原则 - 结果是您将对页面加载做出超级快速的响应。 这才是高流量网站真正需要的。
可以在此处找到一些展示如何提高网站性能的演示文稿：
Michael Koziarski 在 2008 年巴黎谈论 Rails 性能on Rails
Jeremy Kemper 在 RailsConf EU'08 上谈论 Rails 性能
也是我所知道的学习如何使用 Rails 的最佳场所正确的缓存是：
I love HAML since it is a good tool for easily writing structured HTML, and generally it is just a joy to use. But it has very little to do with choosing a tool based on the amount of traffic a site might have.
If you are worried about traffic, you should worry about using caching properly. And then you need to apply the principles of general web-application performance - the result is that you will have super snappy responses to page loads. Which is what a high-traffic website really needs.
A couple of presentations that show how to improve website performance can be found here:
Michael Koziarski speaks about Rails Performance on 2008 Paris on Rails
Jeremy Kemper talks about Performance on Rails on RailsConf EU'08
And the best place that I know of to learn how to use rails caching properly is:
我认为这完全是个人喜好和可维护性的问题。 对我来说，Haml 使模板更易于阅读和理解，并且性能非常可以接受。 最后，模板语言不太可能是您需要优化的地方 - 更有可能是数据库查询、视图或对象缓存等。
但是，对于 ERb 模板，如果满足以下条件，您将基本上免费获得更好的性能：你用的是erubis。
I think it's entirely a matter of personal preference and maintainability. For me, Haml makes the templates easier to read and understand, and the performance is very acceptable. In the end, the templating language is unlikely to be the place where you need to optimize -- more likely database queries, view or object caching, etc.
However, in the case of ERb templates, you will get better performance essentially for free if you use erubis.
如果您从编码的角度喜欢 haml 的工作方式，则不必太担心模板引擎的性能。 （不过，正如您所指出的，它现在速度很快。）它绝对可以生成其他引擎可以生成的任何输出。
一般来说，将精力投入到设置缓存上比担心模板引擎出现性能问题更有利可图。
If you like how haml works from a coding point of view, don't worry about the performance of the templating engine too much. (Though, as you've pointed out, it's now fast.) It can definitely generate any output the other engines can.
Generally, it's more profitable to put your energy into setting up caching than worrying about your templating engine where you're having performance problems.
我个人会向我们推荐预编译模板中的 erubis。
特别是在不需要动态模板的情况下。 那么你最大的减慢将受到 ruby 解析 ruby 的速度的限制。
我可能会设置一个小型 cron 作业，仅监视更改的源模板并在更改时自动编译它们，您可以在不使用时将其关闭。
编译一次，使用多次。
哦，如果你真的很关心速度，Tenjin 可能也值得一看（与 erubis 相同的创建者）
http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html
I would personally recommend us erubis in precompiled templates.
Especially if there's no need for dynamic templating. Then your biggest slowdown will be limited by the speed at which ruby can parse ruby.
I'd probably set up a small cron job that just monitors for changed source templates and autocompiles them on-change that you can turn off when not in use.
Compile once, use many.
Oh, and if you're really concerned about speed, Tenjin may be worth a look too ( same creators as erubis )
http://www.kuwata-lab.com/tenjin/rbtenjin-examples.html
嗯，Haml 的性能随着每个版本的发布而不断提高。 目前处于可接受的位置吗？ 这由你决定（我倾向于说“是”，但这是你根据你的需要做出的选择）。 如果您喜欢模板及其提供的可读性，那么性能下降（无论多么微不足道）应该真正成为您决定的最终因素。
您应该考虑与 Haml 结合使用的其他工具之一是 make_resourceful，这是 Haml 维护者 (Nathan Weizenbaum) 的另一个瑰宝，它简化了 Rails 应用程序中的许多 RESTful 事物。
如果您对 Haml（和 m_r）有任何进一步、更具体的问题，我相信 Nathan 会非常乐意回答。 可以通过 Jabber/XMPP 和电子邮件联系他。 您可以在此处找到他的联系信息。
Well, Haml performance continues to improve with each release. Is it at an acceptable place at the current time? That's for you to decide (I'm inclined to say "Yes", but it's your choice based on your needs). If you like the templates and the readability they provide, then the performance drop (however negligible) should really be the final factor in your decision.
One of the other tools you should consider using in conjunction with Haml is make_resourceful, another gem by the maintainer of Haml (Nathan Weizenbaum) that simplifies a lot of the RESTful things in a Rails app.
If you have any further, more specific questions about Haml (and m_r), I'm sure Nathan would be more than happy to answer them. He can be reached via Jabber/XMPP and email. His contact information can be found here.