为何要使用JS模板引擎

我以前在写一个输入联想控件的时候，改过好几个版本，每一个版本不是由于性能很差就是由于代码凌乱而被推翻，最后用了understore模板引擎，效果有明显改善。整好这两天在研究互联网技术架构，发现不少的开发框架前端都是使用js模板引擎，感悟真的是大道至简，异曲同工啊，哈哈。

 

关于为何使用js模板引擎，在博客园发现园友的一片文章《js模版引擎handlebars.js实用教程——为何选择Handlebars.js》，该文已经作了详细解答。下面内容转自该文：

 

 据小菜了解，对于java开发，涉及到页面展现时，比较主流的有两种解决方案：

         1. struts2+vo+el表达式。

         这种方式，重点不在于struts2，而是vo和el表达式，其基本思想是：根据页面须要的信息，构造出一个实体，这个实体中包含了界面须要的全部属性，一般这个实体是由N个表中的字段构成的，俗称vo。因为vo的属性能够是String、List、Map等等等，又能够vo套vo，所以这种方式很是灵活，也很是好用。

         在后台对vo进行赋值，经过struts2封装到request中，而后在界面用el表达式，一般是${}、forEach标签什么的，便可构造出界面。

         但这种方式小菜却不是很看好。由于这种利用标签控制html，依然是把表现和控制混杂在一块儿，html里边混杂了大量el控制标签，很不美观。

         固然，小菜不可能由于这么简单的理由拒绝这种方式，读者仔细思考能够发现，利用el表达式生成html代码，这是一个在服务器端执行的动做，在服务器端解析完成以后，才发送到客户端浏览器上，这样作会占用大量服务器资源，并且速度缓慢。

         示例代码：

<c:forEach var='bm' items="${contractAuditVo.borrowerModels}">
  <table>
    <tbody>
      <tr>
        <td>借款人编号：</td>
        <td>
          <p>
            ${bm.borrowerId }
          </p>
        </td>
      </tr>
      <tr>
        <td>客户编号：</td>
        <td>
          <p>
            ${bm.customerId }
          </p>
        </td>
      </tr>
      <tr>
        <td>曾用名：</td>
        <td>
          <p>
            ${bm.usedName }
          </p>
        </td>
      </tr>
    </tbody>
  </table>
</c:forEach>

2. Json+ajax+拼html。

         这种方法通常是基于ajax请求，要求服务器端返回一个json类型的json字符串，这个json串中包含了界面所需的全部信息，界面拿到json串后，构造出html，完成界面展现。

         小菜推荐这种方法，经过这种方式编写的页面，反应速度很是快，用户体验很是好。

         由于服务器端只须要提供一个json串，由客户端完成解析，所以服务器承受的压力很小，目前的电脑配置都较高，客户端的浏览器解析js脚本很快，所以页面体验效果好。

         解析的过程大体是经过Jquery的each方法，进行遍历。

         可是小菜利用这种方式时，犯了一个致命的错误，小菜是经过原始的拼接html的方式，页面中写了大量html+=”<div>”;，这种写法使页面变得很是凌乱，几乎不能够维护。

         示例代码：

var contractTextHtml="";
$.each(jsonObject.cl,function(i,n){
  
  contractTextHtml="";
  
  //插入合同文本数据
  contractTextHtml+="<div title='出借人信息---"+hiddenNull(n.cm.lenderName)+"' style='overflow:auto;padding:5px;'>";
  contractTextHtml+="<table class='ui-table ui-table-noborder'>";
  contractTextHtml+="<tbody>";
  contractTextHtml+="<tr><td>合同编号：</td><td><p>"+hiddenNull(n.cm.contractId)+"</p></td></tr>";
  contractTextHtml+="<tr class='ui-table-split'><td>出借人姓名：</td><td><p>"+hiddenNull(n.cm.lenderName)+"</p></td></tr>";
  contractTextHtml+="<tr><td>出借人证件类型：</td><td><p>"+hiddenNull(n.cm.lenderIdType)+"</p></td></tr>";
  contractTextHtml+="<tr class='ui-table-split'><td>出借人证件号：</td><td><p>"+hiddenNull(n.cm.lenderIdNum)+"</p></td></tr>";
  contractTextHtml+="<tr><td>出借金额：</td><td><p>"+hiddenNull(n.cm.lenderAmount)+"</p></td></tr>";
  contractTextHtml+="<tr class='ui-table-split'><td>出借人编号：</td><td><p>"+hiddenNull(n.cm.lenderNo)+"</p></td></tr>";
  contractTextHtml+="<tr><td>出借人银行账号：</td><td><p>"+hiddenNull(n.cm.lenderBankAccount)+"</p></td></tr>";
  contractTextHtml+="<tr class='ui-table-split'><td>撮合编号：</td><td><p>"+hiddenNull(n.cm.makeMatchNo)+"</p></td></tr>";
  contractTextHtml+="</tbody>";
  contractTextHtml+="</table>";
  contractTextHtml+="</div>";
  $("#textList").append(contractTextHtml);
});

 形成这种问题的根本缘由在于拼接html打乱了html原有的层次结构，看不出来哪里是哪里，没有了层次结构的代码，堆在那里就像是一坨垃圾。

         el表达式构造html优势是可以保持html原有格式，js构造html优势是速度快省资源，为何咱们不能把两者的优势结合在一块儿呢？这就是Handlebars.js。

         既然要在项目中引入js模版引擎，就必须进行技术选型，严格考核以后，才能够引入，就好像是木桶效应，不能让他成为项目中的短板。

         Handlebars.js是一款基于Jquery的插件，以json对象为数据源，支持逻辑判断、循环等操做，同时具备很是好的扩展性，体积60KB左右，通过小菜仔细的分析研究，这是一款不可多得的js模版引擎。