handlebars 是否需要扩展包

[popomore]

现在使用 handlebars 时基础功能还是有局限的，比如 if 不能判断表达式，不支持 else if。

{{#if x > 1}}
{{/if}}

我们是否需要提供扩展包来支持一些常用的逻辑，一般业务组件的逻辑比较复杂。

ps：#if 会在 velocity 的模版引擎报错，对贵公司的模版引擎汗颜的情况下还是需要做兼容方案。

[lifesinger]

这是有意设计的，可以看下面两篇文章：

• http://thinkvitamin.com/code/handlebars-js-part-2-partials-and-helpers/
• http://blog.getify.com/grab-ui-by-the-handlebar

简言之，logic-free 的设计，可以让以前一直纠缠不清的展现逻辑和业务逻辑得到“强制”区分，业务逻辑只能写在数据处理层，模板层则只有很纯粹的展现逻辑。

比如对于小高说的这个需求：

{{#if x > 1}}
{{/if}}

可以重构为：

{{#if multiple}}
{{/if}}

核心是要找出 x > 1 背后的意义，并在数据转换层处理好后再输出，这样，以后即便条件变成了 x > 2, 要修改的只是数据层，展现模板层则不需要做任何修改。

[lifesinger]

误关闭了，重新打开，并发散讨论一下：

模板引擎越强大越好吗？来，在此讨论下。正方：存在就是合理的，logic-free 的模板引擎是垃圾。反方：存在的未必是最佳实践，有限制的自由才是真轻松。欢迎各抒己见。

估计没多少人感兴趣，不过这个事情其实挺重要的，呵呵。

[majorye]

@lifesinger 我的观点是Less is More. 对于官方的，只需要提供基本的功能就可以，然后提供一些扩展的机制即可。

对于你提出来的讨论，我站在反方队列，因为太过自由，就会天马行空，最后就是'百花齐放'. 适当的限制，只要有 利于项目，有利于代码的简洁，可读，可维护等，为什么不？ 如mvc ,mvp pattern等

[marksueh]

logic-less的模版引擎的话有利于解耦，mustache.js在chrome下渲染10万个li节点的时间也就300毫秒左右，如果非得说logic-less的性能差，那我觉得当引起模版引擎的性能问题的时候，页面的交互设计必然是有大问题。C语言创使之初，程序员们也都不肯用模块化的函数，因为有性能问题，但是随着时间的推移，性能都不会是问题。

[aui]

最牛逼强大技术不一定能够派上用场，就如同YUI与jQuery一样。换成模板引擎同样适用，极端不可取（如 mustache），我倾向中庸之道：

1、简单易于学习的语法

2、不能牺牲基本的特性

3、尽量清晰的语法

4、可扩展

这是我喜欢的语法：

条件：{if ...} {else if ...} {else} {/if} 遍历：{each ...} {/each} 包含：{include ...} 输出：{content}

[lepture]

handlebars 目前最大的问题是和贵公司的 velocity 模板引擎不兼容。不宜在此讨论，明天聊。

[lifesinger]

@lepture 这个是小问题啦，只要同时支持 {{#xx}} 和 @xx 就好，在调用 Handlebars.compile 之前，先把 {{@ 统一替换成 {{# 就好。

[hite]

mustache用过，最无法忍受的是不支持if else,foreach里连index都没有，所以linkedin自己最后选了dust，不过dust语法太乱了，无法忍受。logicless这种强制的约束目前带来的好处不够，知道mv分离的理念，用jqote这样的logicfree的语言也能学出logicless的feelings。而且性能很好，

[cyjake]

其实 KISSY Template 蛮管用的，哈哈哈

[jinze]

同样不能忍受mustache里没有index的each 有点走极端了

[aui]

我的实现: https://github.com/aui/artTemplate

[lifesinger]

这个我关闭了，一般来说，应该可以通过调整数据输出或通过 helpers 来解决。如果不能解决，我们就再引入一个有 logic 的模板引擎，反正目前的模式下，模板引擎是可替换的，呵呵。

关键看场景。