Mustache.js和Handlebars.js有什么区别？

我看到的主要区别是：

• 把手增加了#if，#unless，#with，和#each
• 把手添加助手
• 车把模板已编译（胡子也可以）
• 车把支撑路径
• 允许使用{{this}}in块（输出当前项目的字符串值）
• Handlebars.SafeString() （也许还有其他方法）
• 车把的速度提高了2至7倍
• 小胡子支撑倒立的部分（即if !x ...）

（如果我对以上内容有误，请纠正我。）

我还有其他主要差异吗？

您已经钉上了钉子，但是还可以编译Mustache模板。

小胡子缺少助手和更高级的方块，因为它努力做到无逻辑。车把的自定义助手可能非常有用，但通常最终会在模板中引入逻辑。

Mustache具有许多不同的编译器（JavaScript，Ruby，Python，C等）。车把开始于JavaScript，现在有django-handlebars，handlebars.java，handlebars-ruby，lightncandy（PHP）和handlebars-objc之类的项目。

小胡子的优点：

• 在大型活跃社区中非常受欢迎的选择。
• 服务器端支持多种语言，包括Java。
• 无逻辑的模板在迫使您将表示与逻辑分离方面做得很好。
• 简洁的语法会导致模板易于构建，读取和维护。

小胡子的缺点：

• 有点逻辑不足：基本任务（例如，用不同的CSS类标记替代行）很困难。
• 视图逻辑通常被推回服务器或实现为“ lambda”（可调用函数）。
• 为了使lambda能够在客户端和服务器上运行，您必须使用JavaScript编写它们。

车把的优点：

• 无逻辑的模板在迫使您将表示与逻辑分离方面做得很好。
• 简洁的语法会导致模板易于构建，读取和维护。
• 编译而不是解释的模板。
• 比胡子（即深入上下文对象）更好地支持路径。
• 对全球帮助者的支持比胡子更好。

车把的缺点：

• 需要服务器端JavaScript才能在服务器上呈现。

来源：客户端模板抛出：小胡子，把手，dust.js等

两个库处理范围的方式之间存在一个细微但重要的区别。如果Moustache在当前上下文中找不到变量，它将回退到父范围。车把将返回一个空白字符串。

GitHub自述文件中几乎没有提到这一点，其中只有一行：

车把与Moustache略有不同，因为它默认情况下不执行递归查找。

但是，如此处所述，有一个标志使车把的行为与“小胡子”相同，但会影响性能。

这会影响您将#变量用作条件变量的方式。

例如，在Mustache中，您可以执行以下操作：

{{#variable}}<span class="text">{{variable}}</span>{{/variable}}

它的基本含义是“如果变量存在并且是真实的，则打印其中包含变量的跨度”。但是在车把中，您要么必须：

• 用{{this}}代替
• 使用父路径，即{{../variable}}回到相关范围
• variable在父variable对象中定义子值

有关更多详细信息，如果需要，请在这里。

注意： 此答案已过时。在发布时确实如此，但现在不再如此。

小胡子有多种语言的口译员，而“把手”仅是Javascript。

它们之间的另一个区别是文件的大小：

• Mustache.js有9kb，
• Handlebars.js的大小为86kb，如果使用预编译的模板，则为18kb 。

要查看Handlebars.js的性能优势，我们必须使用预编译的模板。

来源：JavaScript模板引擎概述

另一个细微的差异是对{{#property}}...{{/property}}块中的虚假值的处理。大多数胡须实现在这里只会服从JS伪造，如果propertyis ''或'0' 则不会呈现该块。

把手将针对''和渲染块0，但不会渲染其他虚假值。迁移模板时可能会造成一些麻烦。

我觉得提到的“车把”缺点之一不再是真的有效。

Handlebars.java现在允许我们为客户端和服务器共享相同的模板语言，这对于具有1000多个需要SEO服务器端渲染的组件的大型项目来说是一个巨大的胜利

看看https://github.com/jknack/handlebars.java

—除了将“ this”用于车把以及将变量块中的嵌套变量用于胡须之外，您还可以将块中的嵌套点用于胡须：

    {{#variable}}<span class="text">{{.}}</span>{{/variable}}