基于TmodJS的前端模板工程化解决方案

　　于TmodJS：TmodJS（原名atc）是一个简单易用的前端模板预编译工具。它通过预编译技术让前端模板突破浏览器限制，实现后端模板一样的同步“文件”加载能力。它采用目录来组织维护前端模板，从而让前端模板实现工程化管理，最终保证前端模板在复杂单页 Web 应用下的可维护性。更多内容，可访问：http://code.csdn.net/news/2820926。

前端模板

早期，开发人员都是直接在 JS 文件中采用最原始的方式直接拼接 HTML 字符串：

var html = '';
for (var i = 0, users = data.users; i < users.length; i ++) {
    html += '<li><a href="'
    + users[i].url
    + '">'
    + users[i].name
    + '</a></li>';
}
//...

　　这种方式刚开始在一两个简单的页面中还是比较灵活的，但弊端也十分明显：UI 与逻辑代码混杂在一起，阅读起来会非常吃力。一旦随着业务复杂起来，或者多人维护的情况下，几乎会失控。

　　受 jQuery 作者的 tmpl 模板引擎影响，从 09 年开始到现在，前端模板引擎出现了百花齐放的局面，涌现出一大批行色各异的引擎，几乎每个前端工程中都使用了模板引擎。一条前端模板类似这样：

<script id="user_tmpl" type="text/html">
{{each users as value}}
    <li>
        <a href="{{value.url}}">{{value.name}}</a>
    </li>
{{/each}}
</script>

　　它使用一个特殊的 <script type="text/html"></script> 标签来存放模板（由于浏览器不支持这种类型的声明，它存放的代码不会当作 JS 运行，代码也不会被显示出来）。使用模板引擎渲染模板的示例：

var html = tmpl('user_tmpl', data);
document.getElementById('content').innerHTML = html;

在线示例

通过前端模板引擎将 UI 分离后，模板的书写与修改就变得简单多了，也提升了可维护性。但是，随着这种方式规模化后其弊端也随之而来。

模板内嵌的弊端

模板内嵌，主要存在 3 个方面的问题，主要包括：

1. 开发调试效率低：每次修改前端模板需要改动页面的代码，如果不是纯静态页面，无法使用类似 fiddler 的工具将页面映射到本地进行开发，开发调试依赖只能服务端环境，效率低下。
2. 自动化构建：在现代 Web 前端工程体系中，几乎每一个环节都拥有相应的优化工具，这些几乎都被 Grunt 这个自动构建工具连接起来。但是前端模板若内嵌到页面中，复杂度会比较高，现有工具因为受限难以进行自动优化。
3. 模块化：前端模板集中在一个文件中这必然会引起多人协作的问题，随着项目复杂度增加，按文件模块化迫在眉睫。

现有的模板外置解决方案与优劣解析

　　目前越来越多的项目已经将模板从页面中迁移出来，主要有两种方式：

1. Ajax 拉取方案

通过 Ajax 加载远程模板，然后再使用模板引擎解析。这种方式的好处就是模板可以按文件存放，书写起来也是十分便利，但弊端相当明显：由于浏览器同源策略限制的，导致模板无法部署到 CDN 网络中。

2. 在 JS 文件中存放模板

为避免上述加载模板方案无法跨域的致命缺陷，模板存放在 JS 文件中又成了最佳实践方式，但是这种情况下需要对回车符进行转义，对书写不友好，严重影响开发效率。例如：

var user_tmpl =
'{{each users as value}}\
    <li>\
        <a href="{{value.url}}">{{value.name}}</a>\
    </li>\
{{/each}}';

或者：

var user_tmpl =
 '{{each users as value}}'
+   '<li>'
+       '<a href="{{value.url}}">{{value.name}}</a>'
+   '</li>'
+'{{/each}}';

现有模板组织方案优劣，如下表对比：

总结：

• 方便优化的模式不利于开发；
• 利于开发的模式不利于优化。