如何選擇Web前端模板引擎（建議）

這篇文章帶給大家的內容是關於如何選擇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: &#39;id1&#39;,
                    name: &#39;John&#39;,
                    inner: [{ title: &#39;a1&#39; }, { title: &#39;b1&#39; }],
                    city: &#39;New York&#39;,
                    active: true
                },
                {
                    id: &#39;id2&#39;,
                    name: &#39;Mary&#39;,
                    inner: [{ title: &#39;a2&#39; }, { title: &#39;b2&#39; }],
                    city: &#39;Moscow&#39;
                }
            ],
            githubLink: &#39;https://github.com/agentcooper/htmltemplate-vdom&#39;,
            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>
    <summary>{{ctx.Description}}</summary>
    <p>
      </p>
<p>{{pkg.Import}}</p>
    
  </details>
  <dl>
    <details>
      <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前端模板引擎（建議）的詳細內容。更多資訊請關注PHP中文網其他相關文章！