動的ページの HTML を手動で生成する JavaScript コード (醜いだけでなく、DRY ではない) を作成することを避け、(パフォーマンスとは対照的に) シンプルさと優雅さを念頭に置くために、文字列ベースを使用する利点は何ですか?サーバー側でレンダリングされた html を取得する REST API を使用するよりも、Mustache.js や Handlebars.js などのクライアントのテンプレートを使用して、json データとテンプレートを個別に取得しますか?
私は、クライアント側のテンプレート化が動的なページでシンプルに保つための最良のアプローチであるという印象を受けましたが、少し使ってみると、そのようなページを維持するのはやや複雑であることがわかりました。その主な利点は、パフォーマンスとパフォーマンスの向上です。通常、これは私の主な目標ではありません。
私は現在 Twitter の Hogan ライブラリを使用しており、それ以前は Trimpath ライブラリを使用していました。私はクライアント側のテンプレート化を真に信じています。しかし、彼らは悪用されるべきではありません。以下にいくつかの引数を示します。
サーバー側のテンプレートと同様に、アプリケーション ロジックとプレゼンテーションを区別するのに役立ちます。実行時に DOM 要素の階層を手動で作成する代わりに、HTML でテンプレートを定義し、javascript からのデータでそれをレンダリングすると、より読みやすく洗練されたコードが作成されます。
Twitter の投稿、ブログ エントリ、ニュース記事などの階層を繰り返すためのクライアント側テンプレートを用意するのが実用的だと思います。サーバーは JSON データのみを送信し (ほとんどの場合、AJAX 呼び出しを介して)、データを送信することができます。すぐにテンプレートにバインドされます。
私が使用したテンプレート エンジンは、生成された HTML 文字列で innerHTML を更新します。これは DOM 操作よりも速いと言われていますが、私自身はベンチマークを実行したことがありません。
デスクトップ アプリケーションと RIA は、クライアント側のテンプレートから多くの恩恵を受けることができます。サードパーティのソリューションに依存せずにインターフェースを駆動できます。
プロジェクトにサーバー側のテンプレートとクライアント側のテンプレートを簡単に含めることができます。彼らは非常にうまく連携できます。Web プロジェクトでは、テンプレートをクライアント側に移植し、サーバーからのみデータを送信することはお勧めしません。たとえば、サーバー側のテンプレートを INCLUDE ステートメントと共に使用して、ページ全体を構築します。1 つのテンプレートに別のテンプレート構造を含めて、インターフェイスを構築できます。これは、不要なコードとオーバーヘッドを作成するクライアント側テンプレートの複雑なタスクです。