选择正确的UI模板工具- dust.js？

Question

我在一个基于Java的大型web应用程序上工作，它是在过去5年左右建立起来的--用户界面需要进行一次彻底的修改/大量重写。我们正在研究要使用的可用UI工具/库/框架，并将dust.js作为模板处理的一种选择。

的问题：，我想听听dust.js的用户是怎么想的：

1. 成功了吗？
2. 用起来容易吗？
3. 有足够的文件吗？
4. 社区支持好吗？(在ST标记'dust.js‘上只有6个问题！)
5. 与其他模板工具(如下划线的模板、Google闭包模板、车把和八字胡 )相比，它们的优缺点是什么？
6. 在MV*结构框架(例如Backbone.js (在线图书) )中使用它有什么问题吗？

一些背景：

• 为什么我们对dust.js感兴趣:下面的LinkedIn博客文章首先引起了我们的注意：

- [Leaving JSPs in the dust: moving LinkedIn to dust.js client-side templates](http://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates)
- [The client-side templating throwdown: mustache, handlebars, dust.js, and more](http://engineering.linkedin.com/frontend/client-side-templating-throwdown-mustache-handlebars-dustjs-and-more) 

--这两篇文章中的第二篇--很好地回答了问题5，但除了LinkedIn之外，很少有来自谷歌详细介绍模板系统的结果，或者暗示它是一种流行的选择。此外，这篇文章还提到，他们已经扩展了功能，并希望有一天能为最初的项目做出贡献。我担心，在他们这么做之前，我们可能还需要扩展功能。

话虽如此，LinkedIn最初对模板系统的要求与我们的非常接近(见下文)，他们在选择之前已经做了一些非常彻底的调查。

​

• 我们的要求：

1. [DRY](http://en.wikipedia.org/wiki/Don%27t_repeat_yourself): We ideally want to use the templating system on the server (Java based) and client-side, or just client-side if we opt for LinkedIn's complete approach; _`Instead of using a JSP, GSP, or ERB to assemble a page server side and send back HTML, we have the server send back just the dynamic data as JSON and have the page assembled in the browser using a static client-side template served from a CDN"`_ 
2. Fully internationalised
3. Good community support
4. Sufficiency easy to use / pick up
5. Works happily with [jQuery](http://jquery.com/) and [Backbone.js](http://documentcloud.github.com/backbone/)
6. Well documented

​

Answer 1

Dust.js是一个很好的选择。它比其他一些模板框架更好，因为它不限制数据应该在文件或字符串中，等等。

此外，它还在积极维护https://github.com/linkedin/dustjs。

1. 成功了吗？ 是的，我知道至少LinkedIn正在使用它，并且也贡献了改进/补丁等等。
2. 用起来容易吗？ 我试过使用它，它和胡子或Handlebars.js一样简单。
3. 有足够的文件吗？ 是的http://akdubya.github.com/dustjs。
4. 社区支持好吗？(在ST标记的“dust.js”上只有6个问题！) 如果你比较小胡子或Handlebars.js，dust.js的用户不多，但我相信如果你有问题并将其发布到LinkedIn回购上，他们肯定会做出回应。我也会看的，因为我正在看:-)
5. 与其他模板工具(如下划线模板、Google闭包模板、把手和胡子)相比，有什么优缺点。 至于优点，您可以检查何时应该考虑使用dust.js这里的https://github.com/linkedin/dustjs#readme。 至于缺点，与流行的dust.js或Handlebars.js相比，还没有足够的用户可供使用。也就是说，像谷歌关闭这样的其他图书馆也面临着同样的问题。 但正如我前面提到的，与其他框架( IMHO )相比，dust.js设计得非常好。
6. 在使用MV*结构框架(如Backbone.js (在线书籍))时是否存在任何问题？ 我没有在其他MVC框架中使用过它，但我认为它根本不应该是一个问题。

希望这能有所帮助。

Answer 2

1. 我现在正在为一家相当大的知名IT公司做一个自由职业项目，他们选择了dust.js作为他们的HTML5移动应用程序框架。没错，LinkedIn是一家大而成功的公司。
2. 说大也大吧。没什么困难的，但我需要适应。我在上与Freemarker合作过，因为有很多内置的功能特性，所以使用起来似乎要容易得多。然而，许多人可能会发现dust.js很好--它有着清晰的逻辑，非常轻量级的语法-- dust.js中有很多东西确实可以让人喜欢。
3. Freemarker的文档记录得更好。对于初学者来说，dust.js的GitHub页面非常好，但是，例如，我找不到所有dust.js过滤器的描述，需要在谷歌上搜索它--然而，搜索很容易为我提供了我所需要的信息。
4. 没有看到太多的社区支持，但图书馆真的很轻量级和清晰-几个谷歌搜索是我所需要的所有必要的信息。
5. 没有使用其他JS模板工具。
6. 我在回答第一个问题时提到的公司已经构建了一个轻量级的HTML5框架，它使用了dust.js以及jQuery和Backbone.js。我一直在为他们做这个项目，使用这个框架，同时利用jQuery和Backbone.js的功能--没什么可抱怨的。dust.js有点像Backbone.js --轻量级的，不会对您的编码风格或使用的其他库施加太多限制。使用它，您将看到有一些更好的JS对象形式，您使用它来为其提供数据，但是很容易习惯(我的意思是，如果您需要视图中的某些内容的列表，最好是使用列表而不是JS对象散列，这在描述单独的实体时是很自然的)。

性能方面的一件事是，您可以使用“完整”版本开发您的应用程序，然后编译您的模板以供生产(例如使用node.js + dust.js npm模块--在这里可以很有用)，以便与“核心”版本一起使用。在这种情况下，您可以大大提高现实世界的性能-将所有的模板放在一起并缩小它们将使客户端浏览器在每次需要时从服务器获取模板。“完整”和“核心”并不是关于商业/免费的-核心版本只是没有模板编译器，将与预编译模板一起使用。