これは、いくつかの興味深い設計上の決定を明らかにするため、実際には非常に興味深い質問です。
部分的なテンプレートをレンダリングすることを好みます。これにより、アプリケーションが時間とともに変化できるようになるからです。<table>からグラフ付きのに変更する必要がある場合<div>、それをテンプレートにカプセル化するのは簡単です。それを念頭に置いて、私はほとんどすべてのページを多くの小さなテンプレートの集合体として見ています。Grails 2.0 のデフォルトのスキャフォールディングは、このタイプのアプローチに移行しており、これは良い考えです。
クライアント側のテンプレートにするか、サーバー側のテンプレートにするかという問題は、問題の核心です。
サーバー側のテンプレートは、最初のページ読み込み時にマークアップをクリーンに保ちます。ICanHazJSのMustacheのようなものを使用する場合でも、ページに空の要素 (テンプレートを使用) を用意し、適切にスタイルを設定し、情報を更新するために Javascript で操作する必要があります。
欠点
- 「おしゃべり」アプリケーション
- ネットワーク全体のより大きなエンベロープ (応答には、静的と見なされる可能性のある HTML が含まれます)
- UI の応答時間が遅い
利点
- サーバーサイド言語の経験が豊富な人に適しています
- サーバー側の環境で操作または変更する方が簡単かもしれません (たとえば、プログラムで読み込まれて含まれる複数のテンプレートが埋め込まれたページを返します)。
- ほとんどのアプリケーションを「1 か所」に保持
ただし、クライアント側のテンプレートを使用すると、サーバーの負荷を大幅に軽減できます。それらは、アプリケーションを「おしゃべりの少ない」ものにします。つまり、JSON のより大きなコレクションを送り返すことで、サーバーへのコールバックの数を最小限に抑えることができる可能性があります (HTML で使用されるバイト数と同じか、それより少ないバイト数で)。サーバー側のテンプレート スキーム)。また、「更新」リンクをクリックしても AJAX ラウンドトリップを行う必要がないため、UI エクスペリエンスが非常に高速になります。一部の人は次のように述べています。
Anthony Eden @aeden 12 月 10 日 返信 リツイートされた お気に入り · Web アプリの未来を開く: 要求は関数によって処理され、ロジックは常に非同期であり、HTML はサーバー上で生成されることはありません。
欠点
- SEO には適していません (最初のページ読み込み時の非セマンティックで無関係な UI 要素)
- いくつかの Javascript foo が必要です (要素を操作するため)
利点 - レスポンシブ - 小さいエンベロープ
トレンドは、特に HTML5 の追加機能 ( など) によって明らかになったクライアント側のテンプレートに移行しているように見えます<canvas>...しかし、それらを活用するためにあまり慣れていないテクノロジに依存する必要があり、Grails パーシャルのほうが快適に感じる場合、それらから始めて、後でパフォーマンスやその他の問題に基づいてクライアント側のテンプレートに向けたリファクタリングを調査することは価値があるかもしれません.