怎样选中Web前端模板引擎（举荐）
模板引擎负责组装数据，以别的一种情势或外不雅展示数据。 阅读器中的页面是 Web 模板引擎终究的展示。
不管你可否直接使用模板引擎，Web 模板不断都在，不在前端就在后端，它的显现乃至可以追溯到超文本标志说话 HTML 标准正式确立此前。
效劳器端的模板引擎
我所知道最早的 Web 模板引擎是 PHP，它正式产生于 1997 年，工作在效劳器端。让我们看看 PHP 官方的 intro-whatis：
HPer 遍及赞许 PHP 本身就是最自然、原生的 PHP 模板引擎，由于她原本就是。在 PHP 的世界里屡次显现过再包装的模板引擎，闻名的有 smarty。
其它效劳器端说话许多都有 HTML 模板引擎，比方 JSP、mustache。
毫无疑问，这些效劳器端模板引擎终究生成的结果是 HTML(XML) 字符串，处置流程逻辑使用宿主说话本身的语法实现。
它们的共同特点：HTML 只是个字符串, 终究结果大概还需要相似 Tidy 这样的清洁或批改验证工具。
这里提出一个问题：二次封装的 smarty 有存在的必要末?
阅读器端的模板引擎
我所知道最早的前端模板引擎是 jCT，它托管于 Google Code，产生于 2008 年，宿主说话是 JavaScript，工作在阅读器中。
今天在 OSC 搜索 JavaScript 模板引擎你会得到 100+ 个结果，下边列举一些：
轻量度：tpl.js、T.js
认知度：arttemplate、mustache.js、doT.js、handlebars.js、pug
DOM-tree-based：domTemplate、transparency、plates
VDOM-based：htmltemplate-vdom、virtual-stache、html-patcher
流行框架：Vue.js、ReactJS、riot
Real-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 <p>Hello <x-search>{this.props.name}</x-search>!</p>;
}
}编译后：
class HelloMessage extends React.Component {
render() {
return React.createElement(
"p",
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 节点。
大约有几种模式(组合)：
1.入口参数是个 Object，模板中的变量 x 是该对象的 .x 属性，例：virtual-stache-example
2.特定语法或属性，比方：Vue.js 的 ...，属性 computed、methods
3.抽象的语义化属性，比方：Vue.js 的 active 这个词适用于多种场景，容易懂得且不发生歧义
4.不负责绑定，需要使用者非常熟知原生办法，用原生办法停止绑定，比方：PowJS
这些模式只是理论方面的，平常是模板引擎设计者要解决的问题。关于使用者来说不如直接问：
1.可以在 HTML 模板中直接写最简便的 console.log(context) 来调试么?
2.可以在多层 DOM 树绑定或传递不一样的上下文参数么?
3.可以在多层 DOM 树内层向上拜访已经生成的 Node 么?
模板引擎团队会给你准确的解决方法，但平常和问题字面描写的目标有所差别。我觉得这就是你评判选中的关键，你对官方给出的准确办法的认可度。
嵌入到 DOM 中
嵌入到 HTML 中
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>
<p if="':';" each="ctx.Package,val-pkg">
<p title="{{pkg.Progress}}: {{pkg.Synopsis}}">{{pkg.Import}}</p>
</p>
</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)->rep
DOM 节点操纵 this.renew、 this.appendTo，这直接渲染到页面 DOM 树
流程操纵 break
伪节点 if="':';"，渲染时基本不生成 p 节点，它是个伪节点，相当于块代码符号 "{}"
关键是整个模板构造，指令语义和 ECMAScript 函数完全一致：
没有数据绑定，你写的是 ECMAScript 函数，传参数好了，要什么绑定
没有事件绑定，每个节点都是真实存在的，直接写 addEventListener 就好了
要调试，随意寻个 do 或 if 或 let 插入 _=console.log(x), 就好了，逗号表达式几乎可以无缝插入所有原生语句
所有的业务逻辑都是使用者本人写的，PowJS 只负责把他们粘合成一个函数
输出视图是 ECMAScript 源码，下图截取自演示 My Folders
那么 PowJS 是终究的选中么？PowJS 的理念是原生性，原生的 DOM，原生的 ECMAScript。
原生也一样是 PowJS 的问题所在，不是所有的使用者都喜爱原生，我信赖有的使用者更喜爱更抽象风格，他们眼中的原生总是带了点 "原始"。
原生意味着你可以扩展，引入其它 library 停止搭配，但 PowJS 永久不会显现 define setter/getter实现的 watcher，那超出了模板引擎的范畴，假如有那必然是独立的项目。
最后，我的观念仍然是：你的需求才是选中模板的关键，适合你的才是好的。
以上就是怎样选中Web前端模板引擎（引荐）的具体内容，更多请关注百分百源码网其它相关文章！
