Web フロントエンド テンプレート エンジンの選択方法 (推奨)

この記事の内容は、Web フロントエンド テンプレート エンジンの選び方に関するものです (推奨)。必要な方は参考にしていただければ幸いです。

テンプレート エンジンは、データを組み立て、別の形式または外観でデータを表示する役割を果たします。ブラウザ内のページは、Web テンプレート エンジンの最終的な表現です。

テンプレート エンジンを直接使用するかどうかに関係なく、Web テンプレートはフロントエンドではなくバックエンドに常に存在していました。その出現は、ハイパーテキスト マークアップが正式に確立される前にまで遡ることができます。言語 HTML 標準。

サーバーサイド テンプレート エンジン

私が知っている最も古い Web テンプレート エンジンは PHP です。これは 1997 年に正式に誕生し、サーバーサイドで動作します。 PHP の公式の概要を見てみましょう:

HP ユーザーは一般に、PHP 自体が最も自然でネイティブな PHP テンプレート エンジンであることに同意します。 PHP の世界には再パッケージ化されたテンプレート エンジンが多数あり、有名なものは Smarty です。

他の多くのサーバーサイド言語には、JSP やMustache などの HTML テンプレート エンジンがあります。

これらのサーバー側テンプレート エンジンによって生成される最終結果は HTML (XML) 文字列であることに疑いの余地はなく、処理フロー ロジックはホスト言語自体の構文を使用して実装されます。

それらの共通の特徴: HTML は単なる文字列であり、最終結果には Tidy などのクリーニングまたは修正検証ツールが必要になる場合があります。

ここに質問があります: 二次的にカプセル化された Smarty は必要ですか?

ブラウザ側のテンプレート エンジン

私が知っている最も古いものフロントエンド テンプレート エンジンは、Google Code 上でホストされ、2008 年に誕生した jCT です。ホスト言語は JavaScript で、ブラウザ上で動作します。

OSC で JavaScript テンプレート エンジンを検索すると、次のような結果が 100 件表示されます。

軽量: tpl.js、T.js
認識: arttemplate、mustache .js。 、doT.js、handlebars.js、pug
DOM ツリー ベース: domTemplate、透明度、プレート
VDOM ベース: htmltemplate-vdom、virtual-stache、html-patcher
人気のあるフレームワーク: Vue。 js、ReactJS、riot
Real-DOM: PowJS

それらの共通機能: すべて補間をサポートしています。

テンプレート エンジンの人気の比較、さらには最高の JavaScript テンプレート エンジンの投票とその長所と短所の理由も掲載されています。

選び方

私は、少なくともアプリケーションや特定の時代においては、どのエンジンやフレームワークにも必ずメリットがあると考えています。特定のエンジンの何が問題なのかについては、客観的ではないのでコメントしないでください。ここで、前述の質問に答えます。smarty は存在する必要がありますか?私の答えは「はい」です。理由は非常に簡単で、誰に使用されるか、そして全体的な背景によって異なります。フロントエンドとバックエンドが分離されていないアプリケーション、またはフロントエンド担当者がバックエンド言語に精通していない場合、または職務上バックエンド言語が必要な場合、フロントエンド担当者がバックエンド言語を習得することが現実的です。逆に、PHP だけで Smarty を使用するのはスキルの無駄です。

以下はエンジン選択に関する一般的な提案です:

前提条件は、選択したエンジンがデータ レンダリングのニーズを満たし、既存の依存関係と競合しないことです。エンジン、それならすでに答えは出ています。

それは 1 回限りのプロジェクト要件ですか? その場合は、学習の複雑さが最も低い軽量なものを選択してください。コンポーネント開発を行いたいですか?

エンジンは事前にコンパイルされた結果をサポートしているため、毎回リアルタイムでコンパイルする必要はありません?

プラットフォームはサポートを提供する公式のものがありますが、React-JSX エンジンまたは純粋な VDOM エンジンが推奨されます。

学習や保守の複雑さが最も低いものを選択してください。ご存知のとおり、開発者はコードの作成よりもデバッグに多くの時間を費やすことを嫌います。

最後のステップはパフォーマンスの比較です。パフォーマンスの比較は非常に詳細なタスクであり、他の人の比較結果が必ずしもあなたのシナリオと一致するとは限りません。

文法スタイルの比較は弱められるべきだと思います。一部の文法には特別な背景があります。

パフォーマンスの比較が最後になるのはなぜですか?

パフォーマンスは確かに重要ですが、パフォーマンスがアプリケーションのエクスペリエンスに影響を与えていない場合は、無視してください。アプリケーション シナリオを実際にシミュレートすることは困難であり、通常、現在のテスト ツールではこの効果を実現できません。

前述の質問の一部には答えが決まっています。コンポーネント開発、プリコンパイルのサポート、複雑さをどのように考慮するかという残りの質問について説明します。

コンポーネント開発

コンポーネント開発は、もはやテンプレート エンジンの選択の問題ではなく、生態学的環境の選択の問題です。アプリケーションをより速く完了する必要がある場合は、時間が最優先であり、使用または参照するのに十分なコンポーネントを備えた人気のあるフレームワークを選択してください。アプリケーションに独立した生態環境があり、長期的なメンテナンスのためにテクノロジーの選択が必要な場合は、以下を読み続けてください。

プリコンパイル

プリコンパイルには次のものが必要です:

コンパイル結果には、ターゲット環境でのコンパイル プロセスが必要なくなります。
デバッグ可能にするために結果をコンパイルします。つまり、結果には純粋なデータの説明ではなく、ネイティブの ECMAScript コードが含まれる必要があります。
React-JSX がプリコンパイルをサポートしていることは誰もが知っています。公式声明では、React Without JSX は常にビルドされることを意味します。

一部の文字列処理ベースのエンジンはプリコンパイルもサポートしています。プリコンパイルが必要な場合は、コンパイル結果が依然として文字列連結に基づいているエンジンを放棄することをお勧めします。これは、HTML5 が広くサポートされる前の技術的な方法でした。

デバッグ可能にするためには、少なくとも React-JSX と同様のコンパイル結果が必要です。注: Vue.js は、同じ効果を実現するために複数のテンプレート エンジンをサポートしています。

Web コンポーネント テクノロジを使用する元の ReactJS コード:

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>

複雑さ

2 つのエンジンのどちらが複雑ではないかを単一の基準で判断することは困難です。これは、ユーザーの思考パターンが異なるためです。たとえば、上記のエンジンの使用方法やプリコンパイル結果の違いはユーザーによって異なります。これが異なるエンジンの存在の合理性であり、価値です。

一部のユーザーは、文字列テンプレートがこのアプリケーション シナリオのニーズを満たすことができ、軽量で十分であると考えています。
一部のユーザーは、文字列スプライシング技術のテンプレート エンジンが十分強力ではなく、十分に最新ではないと考えています。
一部のユーザーは、OOP は十分に合理的で、十分に論理的で、十分に抽象的であると考えています。
一部のユーザーは、ネイティブ HTML をフロントエンドと呼ぶと考えています。
一部のユーザーは、VDOM の適用範囲が広いと信じています。

これらの判断には独自の理由があり、焦点や基準も異なります。しかし、それらの共通点からその複雑さを考慮することはできます。

String クラス テンプレートは通常非常に軽量であるため、このセクションの範囲を超えています。非文字列テンプレートの複雑さを判断するための一般的な基準は何ですか?データバインディングの複雑さも考慮できると思います。

この記事で言及するデータ バインディングには、補間だけではなく、コンテキストやイベント、さらにはランタイム全体のホスト環境も含まれます。

実際、VDOM は実際の DOM ノードにマッピングできるため、少なくとも VDOM レベルに達するエンジンにはこの機能が必要です。

おそらくいくつかのモード (組み合わせ) があります:

1. エントリ パラメーターはオブジェクトであり、テンプレート内の変数 x はオブジェクトの .x 属性です (例: virtual)。 -stache-example
2. 特定の構文または属性 (Vue.js の...、計算された属性、メソッド) #3. 抽象的なセマンティック属性 (Vue.js の active) が適切です。さまざまなシナリオに対応しており、理解しやすいです。##4 は、バインディングを担当する必要はなく、バインドには次のようなネイティブ メソッドを使用する必要があります。
#これらのモードは理論上のものであり、通常は解決すべきテンプレート エンジン設計の問題です。ユーザーに対しては、次のことを直接尋ねたほうがよいでしょう:

1. 最も単純な console.log(context) は、デバッグ用に HTML テンプレートに直接記述できますか?

2.レイヤー DOM ツリーですか? それとも、別のコンテキスト パラメーターを渡しますか?

3. 生成されたノードは、マルチレイヤー DOM ツリーの上にアクセスできますか?

テンプレート エンジン チームが正しい解決策を提供しますが、通常は、文字通りに説明される目標はさまざまです。これがあなたの選択の判断、当局から与えられた正しい方法の認識の鍵であると思います。

DOM への埋め込み

HTML への埋め込み

PowJS は次のように実装されます:

テンプレートを実装するために実装する必要がある指示

Pre-コンパイルされた出力ネイティブ ECMAScript コード

テンプレートの構文構造は ECMAScript 関数の記述方法と一致しています

結局のところ、PowJS テンプレートの記述は ECMAScript 関数の記述と似ています。

GoHub インデックスでの記述

<template>
  <details>
    <summary>{{ctx.Description}}</summary>
    <p>
      </p>
<p>{{pkg.Import}}</p>
    
  </details>
  <dl>
    <details>
      <summary>{{rep.synopsis}}</summary>
    </details>
  </dl>
</template>

ほとんどのテンプレート エンジンは、if および each 命令を実装します。

グローバル オブジェクトは、sel

Template ( function) 命名リポジトリ、リスト

テンプレート (関数) エントリ パラメーター データ

カスタマイズされたローカル変数 ctx
下位テンプレート (関数) パラメーター導出データ.sha->sha
Traversal 値は、下のテンプレート パラメーター (ctx.Package,val-pkg)->pkg、(data.content,val-rep)->rep
DOM ノード操作 this.renew、this.appendTo、これは直接レンダリングされますページ DOM ツリー
プロセス制御ブレーク
疑似ノード if="':';" の場合、p ノードはレンダリング中にまったく生成されません。これは、ブロック コード記号 "{}" に相当する疑似ノードです。
重要なのは、テンプレート構造全体、命令セマンティクス、および ECMAScript 関数がまったく同じであるということです。

データ バインディングはありません。ECMAScript 関数を作成し、パラメーターを渡すだけです。どのようなバインディングを行うか
イベント バインディングはありません。すべてのノードは実際です。addEventListener を直接書き込むだけです。

デバッグするには、do または if または let を見つけて _=console.log(x) を挿入するだけです。カンマ式はほぼシームレスに挿入可能 すべてのネイティブ ステートメント

すべてのビジネス ロジックはユーザー自身によって記述され、PowJS はそれらを関数に結合することのみを担当します
エクスポートされたビューは ECMAScript ソース コードであり、次の図が撮影されます。デモから My Folders

結局、PowJS が最終的な選択肢になるのでしょうか? PowJS の概念は、ネイティブ性、ネイティブ DOM、ネイティブ ECMAScript です。

ネイティブも PowJS の問題です。すべてのユーザーがネイティブを好むわけではありません。ユーザーの目には、ネイティブは常に少し「独創的」であると思われます。

ネイティブとは、マッチングのために他のライブラリを拡張および導入できることを意味しますが、PowJS には setter/getter の定義によって実装されるウォッチャーはありません。これはテンプレート エンジンの範囲を超えます。存在する場合、それは独立したプロジェクトである必要があります。 。

最後に、私が言いたいのは、テンプレートを選択するにはニーズが重要であり、自分に合ったものが最適であるということです。

以上がWeb フロントエンド テンプレート エンジンの選択方法 (推奨)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。