模板引擎卖力组装数据，以其余一种形式或外不雅观展现数据。 浏览器中的页面是 Web 模板引擎终极的展现。
无论你是否直策应用模板引擎，Web 模板一贯都在，不在前端就在后端，它的涌现乃至可以追溯到超文本标记措辞 HTML 标准正式确立之前。
做事器真个模板引擎
我所知道最早的 Web 模板引擎是 PHP，它正式出身于 1997 年，事情在做事器端。让我们看看 PHP 官方的 intro-whatis：
PHP（“PHP: Hypertext Preprocessor”，超文本预处理器的缩写）是一种被广泛运用的开放源代码的多用场脚本措辞，它可嵌入到 HTML中，尤其适宜 web 开拓。
PHPer 普遍赞许 PHP 本身便是最天然、原生的 PHP 模板引擎，由于她本来便是。在 PHP 的天下里多次涌现过再包装的模板引擎，著名的有 smarty。
其它做事器端措辞很多都有 HTML 模板引擎，比如 JSP、mustache。
毫无疑问，这些做事器端模板引擎最终生成的结果是 HTML(XML) 字符串，处理流程逻辑利用宿主措辞本身的语法实现。
它们的共同特色：HTML 只是个字符串, 终极结果可能还须要类似 Tidy 这样的清洁或改动验证工具。
这里提出一个问题：二次封装的 smarty 有存在的必要么?
浏览器真个模板引擎
我所知道最早的前端模板引擎是 jCT，它托管于 Google Code，出身于 2008 年，宿主措辞是 JavaScript，事情在浏览器中。很荣幸，我便是 jCT 的作者，干系早期博客可以查看 achun、github jCT 备份。
直到本日写这篇文章，我才创造 pure-js 这篇文章里面也提到不少先行者——jemplate 最早在 2006 年就创建了。
本日在 OSC 搜索 JavaScript 模板引擎你会得到 100+ 个结果，下边列举一些：
轻量度：tpl.js、T.js认知度：arttemplate、mustache.js、doT.js、handlebars.js、pugDOM-tree-based：domTemplate、transparency、platesVDOM-based：htmltemplate-vdom、virtual-stache、html-patcher盛行框架：Vue.js、ReactJS、riotReal-DOM：PowJS它们的共同特色：全都支持插值。
这里还有 templating-engines 受欢迎度的比拟，乃至 best-javascript-templating-engines 投票及正反方的情由。
如何选择
我认为存在即合理，每个引擎、框架总有可取之处，至少在你的运用里，在某个时期，以是本文不会评论某个引擎哪一点不好，那样是不客不雅观的。现在回答前边提到的问题：smarty 有存在的必要么？我的答案是：有。情由很大略，看给谁用、看大背景。对付前后端没有分离的运用，或前端职员对后端措辞不足熟习，或因岗位职责须要，那么前端职员节制一种比较通用的模板语法(措辞)是现实的，反之让 PHPer 自己去利用 smarty 那就太摧残浪费蹂躏技能了。
下面是常日意义上的引擎选择建议：
条件，选择的引擎能知够数据渲染需求，且反面现有依赖冲突，如果你已经非常熟习某个引擎，那你已经有答案了。是一次性的项目需求么? 是的话直接选择轻量的，学习繁芜度最低的。是要做组件开拓么?引擎支持预编译结果，不必每次都实时编译么?要跨平台么? 有官方供应支持的，首选类 React-JSX 的引擎或纯粹的 VDOM 引擎。选择学习或掩护繁芜度最低的，众所周知，开拓者对调试的韶光超过写代码的韶光切齿腐心。末了才是性能比拟，性能比拟是一件非常细致的事情，他人的比拟结果不一定符合你的场景。我认为该当弱化语法风格的比拟，偏好是没有可比性的，一些语法乃至有分外的背景缘故原由。
为什么末了才是性能比拟？
性能的确很主要，但如果性能还没有影响到你的运用体验度，那就忽略它。很难真实地仿照运用处景，常日只有通过真实场景来考验，目前的测试工具还达不到这种效果。
前述问题有些有固定答案，下面谈论余下的问题：如何考虑组件开拓、支持预编译、繁芜度？
组件开拓
进行组件开拓已经不再是选择模板引擎的问题了，这是生态环境选择的问题。如果你的运用须要更快地完成，那么韶光点是第一位的，就选择盛行框架，有足够多的组件让你利用或参考。如果你的运用有独立的生态环境，须要技能选型以便长期掩护，那连续看下文。
预编译
预编译该当具备：
编译结果在目标环境中不再须要编译过程。编译结果可调试性，这意味着结果该当包含原生 ECMAScript 代码，而不是纯粹的数据描述。大家都知道 React-JSX 是支持预编译的，官方的说法是 React Without JSX，即总是 build 过的。
一些基于字符串处理的引擎也支持预编译。如果你须要预编译，建议抛弃编译结果依然是基于字符串拼接的引擎，那样还不如不预编译，那是 HTML5 未被广泛支持之前的技能手段。
至少也要有类似 React-JSX 这样的编译结果才具有可调试性。备注：Vue.js 支持多种模板引擎，可达到同样的效果。
原 ReactJS 代码，个顶用到了 Web Components 技能：
class HelloMessage extends React.Component { render() { return <div>Hello <x-search>{this.props.name}</x-search>!</div>; }}
编译后：
class HelloMessage extends React.Component { render() { return React.createElement( \公众div\"大众, null, \公众Hello \"大众, React.createElement( \"大众x-search\"大众, null, this.props.name ), \"大众!\公众 ); }}
不少 VDOM 引擎也可以编译类似效果，比如 htmltemplate-vdom。
<script> var id = 3; var env = { people: [ { id: 'id1', name: 'John', inner: [{ title: 'a1' }, { title: 'b1' }], city: 'New York', active: true }, { id: 'id2', name: 'Mary', inner: [{ title: 'a2' }, { title: 'b2' }], city: 'Moscow' } ], githubLink: 'https://github.com/agentcooper/htmltemplate-vdom', itemClick: function(id) { env.people.forEach(function(person) { person.active = String(person.id) === String(id); }); loop.update(env); } // Omitted .... }; </script>
繁芜度
很难用唯一的标准去评判两个引擎哪个繁芜度低，这是由利用者的思维模式不同造成的。例如前边列出的引擎在利用上以及预编译结果上的差异，不同利用者感触是不同的，这正是不同引擎存在的合理性、代价性。
有的利用者认为这个运用处景有字符串模板就知足了需求，轻量够用。有的利用者认为字符串拼接技能的模板引擎不足强壮，不足时期感。有的利用者认为 OOP 够理性，够逻辑，够抽象。有的利用者认为原生 HTML 才叫前端。有的利用者认为 VDOM 适用性更广。这些评判都有各自的情由，着眼点不同，标准也就不同了。但是我们还是可以从它们的共性去考虑它们的繁芜度。
字符串类模板常日都很轻量，不在本节谈论范围之内。对付非字符串模板繁芜度评判的共性标准是什么？我认为，可以考量数据绑定的繁芜度。
本文所指的数据绑定不但是插值，还包括高下文以及事宜，乃至是全体运行期的宿主环境。
事实上至少须要达到 VDOM 级别的引擎才具有这种能力，由于通过 VDOM 可以映射到真实的 DOM 节点。
大概有几种模式(组合)：
入口参数是个 Object，模板中的变量 x 是该工具的 .x 属性，例：virtual-stache-example特定语法或属性，比如：Vue.js 的 <a v-on:click=\"大众doSomething\"大众>...</a>，属性 computed、methods抽象的语义化属性，比如：Vue.js 的 active 这个词适用于多种场景，随意马虎理解且不产生歧义不卖力绑定，须要利用者非常熟习原生方法，用原生方法进行绑定，比如：PowJS这些模式只是理论方面的，常日是模板引擎设计者要办理的问题。对付利用者来说不如直接问：
可以在 HTML 模板中直接写最大略的 console.log(context) 来调试么?可以在多层 DOM 树绑定或通报不同的高下文参数么?可以在多层 DOM 树内层向上访问已经天生的 Node 么?模板引擎团队会给你精确的办理办法，但常日和问题字面描述的目标有所差异。我以为这便是你评判选择的关键，你对官方给出的精确方法的认可度。
嵌入到 DOM 中
嵌入到 HTML 中
这是本文开篇 PHP 自述里面的话，历史缘故原由使得 PHP 依然是做事器真个超文本预处理器，HTML 在 PHP 中依然是字符串，但是：PHP 视角中的 HTML 便是字符串，PHP 真的无缝嵌入到 HTML 这个 \"大众宿主\"大众 中了。
在 WEB 业内标准完善，环境大大改进的本日，前端模板引擎能不能打破仅仅嵌入到 HTML 字符串或嵌入到 VDOM，能不能真正地
嵌入到 DOM 中
PowJS 做到了这一点，实在我也是 PowJS 的设计者。PowJS 是这么实现的：
实现模板必须要实现的指令预编译输出原生 ECMAScript 代码模板语法构造与 ECMAScript 函数写法同等终极，写 PowJS 模板就像在写 ECMAScript 函数。
GoHub index 中的写法
<template> <details func=\公众repo\"大众 param=\公众data\"大众 if=\公众is.object(data.content)&&!sel(`#panel details[sha='${data.sha}']`)\"大众 open let=\公众ctx=data.content\"大众 sha=\"大众{{data.sha}}\"大众 origin=\"大众{{ctx.Repo}}\公众 repo=\"大众{{data.owner}}/{{data.repo}}\"大众 subdir=\公众{{ctx.Subdir||''}}\公众 filename=\公众{{ctx.Filename}}\"大众 render=\公众:ctx\公众 do=\"大众this.renew(sel(`#panel details[repo='${data.owner}/${data.repo}']`))\公众 break > <summary>{{ctx.Description}}</summary> <div if=\公众':';\"大众 each=\"大众ctx.Package,val-pkg\"大众> <p title=\"大众{{pkg.Progress}}: {{pkg.Synopsis}}\"大众>{{pkg.Import}}</p> </div> </details> <dl func=\"大众list\"大众 param=\"大众data\"大众 if=\"大众!sel(`#panel details[sha='${data.sha}']`)&&':'||'';\"大众 each=\公众data.content,data.sha,val-rep\"大众 do=\公众this.appendTo(sel('#panel'))\"大众> <details sha=\公众{{sha}}\"大众 repo=\"大众{{rep.repo}}\公众> <summary>{{rep.synopsis}}</summary> </details> </dl></template>
多数模板引擎都会实现 if 、each 这些指令，上面的 PowJS 模板中还有：
全局工具 is、sel模板(函数)命名 repo 、list模板(函数)入口形参 data自定义局部变量 ctx下层模板(函数)形参推导 data.sha->sha遍历值到下层模板形参推导 (ctx.Package,val-pkg)->pkg 、(data.content,val-rep)->repDOM 节点操作 this.renew、 this.appendTo，这直接渲染到页面 DOM 树流程掌握 break伪节点 if=\"大众':';\"大众，渲染时根本不天生 div 节点，它是个伪节点，相称于块代码符号 \公众{}\公众关键是全体模板构造，指令语义和 ECMAScript 函数完备同等：
没有数据绑定，你写的是 ECMAScript 函数，传参数好了，要什么绑定没有事宜绑定，每个节点都是真实存在的，直接写 addEventListener 就好了要调试，随便找个 do 或 if 或 let 插入 _=console.log(x), 就好了，逗号表达式险些可以无缝插入所有原生语句所有的业务逻辑都是利用者自己写的，PowJS 只卖力把他们粘合成一个函数导出视图是 ECMAScript 源码，下图截取自演示 My Folders那么 PowJS 是终极的选择么？PowJS 的理念是原生性，原生的 DOM，原生的 ECMAScript。
原生也同样是 PowJS 的问题所在，不是所有的利用者都喜好原生，我相信有的利用者更喜好更抽象风格，他们眼中的原生总是带了点 \公众原始\"大众。
原买卖味着你可以扩展，引入其它 library 进行搭配，但 PowJS 永久不会涌现 define setter/getter实现的 watcher，那超出了模板引擎的范围，如果有那一定是独立的项目。
末了，我的不雅观点依然是：你的需求才是选择模板的关键，适宜你的才是好的。
作者先容
喻恒春，野生程序员，常年出没于 bug 丛林。
