JavaScriptはいつHTMLを生成する必要がありますか？

JavaScriptからできるだけ少ないHTMLを生成しようとします。代わりに、Ajaxを使用するのに適していない要素を動的に挿入する必要がある場合にのみ、HTMLを生成でき、既存のマークアップを操作することを好みます。これにより、マークアップの読み取りとトレースが容易になるため、コードの保守とコードの変更がはるかに簡単になります。私の経験則では、HTMLはドキュメント構造用、CSSはプレゼンテーション用、JavaScriptは動作用です。

しかし、フォーム全体やコンテンツが多いモーダルダイアログなど、HTMLの山を生成するJSコードをたくさん見ました。一般的に、どの方法がベストプラクティスと見なされますか？どのような状況でJa​​vaScriptを使用してHTMLを生成する必要がありますか？

JavaScriptで大量のHTMLが生成されるたびに、それはほとんどスタンドアロンのUIプラグインのみでした。プラグイン全体を単一の.jsファイル（+スタイルをカスタマイズする.css）にカプセル化できるため、アプリケーションで使用されるフレームワークから簡単に再利用可能、配布可能、独立できるため、これは理にかなっています。

したがって、さまざまなアプリケーションで使用したいスタンドアロンのJavaScriptプラグインまたは汎用UIコンポーネントを作成している場合、このようなアプローチには利点があります。それ以外の場合、html生成をjavascriptからサーバー側で遠ざけると、よりクリーンで、作成しやすく、保守しやすくなると思います。

問題は、きちんと書かれたサーバー側のテンプレートと、ひどく書かれたアドホックなクライアント側のHTML生成を比較していることだと思います。もちろん、きれいに書かれたコードは読みやすく、保守しやすく、トレースしやすいです。

クライアント側のコードを「HTMLの山」と呼びますが、もちろん、生成される場所はどこでも同じHTMLです。「マウンド」は本当に大きなコードの塊です。

クライアント側のテンプレートライブラリはたくさんあります。それらはサーバー側のものと同様に機能します。どちらを優先するかについては、パフォーマンスのトレードオフは複雑ですが、JSONは通常、HTMLよりもコンパクトであり、クライアントにテンプレートがあると、サーバー呼び出しがいくつかなくなる可能性があります。一方、クライアントのJSが無効になっているか、実用的となるには遅すぎる可能性があるため、ターゲットオーディエンスにも依存します。全体として、アプローチはかなり比較可能であると思います。最大の要因は対象読者のブラウザ機能です。

ただし、実行している内容、サーバー環境よりもJSを好むかどうか、どのテンプレートソリューションを好むかなどに依存します。

クライアント側のテンプレートを使用する傾向があります。極端な場合、サーバーはすべてのクライアント側のレンダリングを行いながら、たとえばJSON形式のRESTful APIのみを提供します。このアプローチの利点は、JSコードとテンプレートが静的なリソースであり、CDNを介してキャッシュ、プロキシ、および配布できることです。サーバー側で生成されたダイナミックHTMLがある場合、これは実行できません。また、RESTful APIから軽量形式でデータのみを返すと、サーバー側のリソースがはるかに少なくなり、応答が速くなります。また、軽量であるため、ネットワーク転送が少なくなり、再び高速になります。これにより、3Gなどの低速接続でも非常に応答性の低い低遅延アプリケーションを使用できます。したがって、このアプローチはモバイルページおよびアプリケーションで一般的です。

JSテンプレートを実装するライブラリは多数ありますが、人気のあるものの1つはPure、 Moustache、およびdust.jsです。後にLinkedInで使用され、記事「JSPをそのままにしておく：LinkedInをdust.jsクライアント側テンプレートに移動する」でその利点を説明しています。

クライアントでHTMLを生成する利点は、各クライアントにレンダリング作業をオフロードすることです。これは通常、応答を待機するアイドル状態です。より多くのサーバーリソースを解放して、JSONデータと静的コンテンツ（HTML、JS、CSS）のみを配信します。

JavascriptでHTMLのみを生成するWebアプリを作成します。サーバーヒットの87％はJSONデータです。通常、静的コンテンツは一度読み込まれ、その後ブラウザキャッシュから読み込まれます。

ただし、SEOが必要な場合は、少なくとも簡単には使用できません。または、Javascriptが無効になっている集団をターゲットにした場合でも、これがYoutube、Twitter、Facebook、Gmailなどに関連するかどうかはわかりません。

動的なページ読み込みに関しては、すべての「JQuery AJAX Cloud！」の背後にあることに気付くはずです。魔法、起こりうる2つのことだけが起こっています。

1. 要素のコードがdivに挿入されている（不良）、または
2. コンテンツはiframeに読み込まれています（より良いですが、同じではありません...）

元の質問に関しては、サーバーに保存されたXMLまたはJSONデータを読み取る何らかの種類のWebアプリを作成するときに、Javascriptを介してHTMLコンテンツのみを作成します。

Javascriptを使用してページに静的コンテンツをロードすることは、正しくロードされない可能性が常にあるか、クライアントがそれを無効にする（「厄介な広告を受け取る！」）可能性があるため、あまり意味がありません。また、HTMLコンテンツがいdocument.write()またはのチェーンの中に押し込まれている場合、HTMLコンテンツを変更するのが非常に難しくなりますdocument.createElement()。

だから、あなたは正しい。生のHTMLを入力するか、動的なコンテンツが必要な場合は、サーバー側のスクリプトを使用して必要なものを出力します。Javascriptを使用してHTMLを挿入するのは、インターネット接続なしでサイトが機能することを意図している場合、または同様の場合のみです。

最後に、xmlhttprequests、er、AJAXをWebサイトに実装する場合、おそらくそれを行うための最良/最も安全な方法は、データをデータ形式（XMLなど）に格納し、それをロードし、それに応じて出力することです。クライアント上。document.writeそしてelement.innerHTML、実際にコンテンツを操作して行くための最善の方法ではなく、将来の潜在的な頭痛を引き起こすことがバインドされている（なぜこのスクリプトが実行されていない？私の壊れ<i>たタグがすべてを斜体れる！など）。

それに関する私の信条は、それが簡単で誰もマークアップを気にしないときです。

また、両方を活用して、マークアップを気にするのが非常に難しい制限を定義し、DOMツリーに集中することもできます。たとえば、動的な行（たとえば、「別の添付ファイルを追加」）があるフォームでは、おそらくHTMLのフォーム、「行の追加」ボタン、および送信ボタンが必要になります...おそらく生成したくないでしょうサーバー側の言語などを含むHTML。

もう1つの経験則は、再利用可能性です。ソリューションをクライアント側の他の問題に適用できる場合は、jsにカプセル化します。

単一ページのアプリ（Google Mailのみ）を構築します。文字通り、サーバー側でHTMLを生成するアプリはまったくありません。代わりに、Backbone.jsを使用してクライアント側を構成し、Handlebarsを使用してJSONをページに入力するテンプレートにレンダリングしています。それは実際に非常にうまく機能し、それを使用する最初のアプリの終わりに近づいており、将来さらに大きなプロジェクトに取り組みます。

サーバーがデータを保持し、クエリ結果を返すためだけに使用されるあらゆる種類のファットクライアントは、JavaScriptでHTMLを生成する場合のポスターチャイルドです。きれいで簡単にするために、必ず優れたテンプレートエンジンを使用してください。

ポートレットを使用しているため、jqueryでhtmlコードを生成しています。jspコードを実行した後、htmlコードでループを作成する必要があります。だから私はjavaarraylistをjavascript配列でレンダリングし、文字列を使用してhtmlを生成しています。