JavaScriptはいつHTMLを生成する必要がありますか？
私はJavaScriptからできる限りHTMLを生成しないようにしています。代わりに、できる限り既存のマークアップを操作し、Ajaxを使用するのに適していない要素を動的に挿入する必要がある場合にのみHTMLを生成することを好みます。これにより、マークアップが読みやすくなり、追跡しやすくなるため、コードの保守とコードへの変更がはるかに容易になります。私の経験則は、HTMLはドキュメント構造用、CSSはプレゼンテーション用、JavaScriptは動作用です。
ただし、フォーム全体やコンテンツを多用したモーダルダイアログなど、HTMLの山を生成する多くのJSコードを見てきました。一般的に、どの方法がベストプラクティスと見なされますか？どのような状況でJavaScriptを使用してHTMLを生成する必要がありますか？
私がJavaScriptで大量のHTML生成に遭遇したときはいつでも、それはほとんどスタンドアロンUIプラグインだけでした。プラグイン全体を単一の.jsファイル（+ .cssでスタイルをカスタマイズする）にカプセル化できるため、簡単に再利用、配布、アプリケーションで使用されるフレームワークから独立させることができるので、それは理にかなっています。
したがって、さまざまなアプリケーションで使用したいスタンドアロンのJavaScriptプラグインまたは汎用UIコンポーネントを作成している場合、そのようなアプローチには利点があります。それ以外の場合は、html生成をJavaScriptから離してサーバー側で維持する方が、クリーンで、記述も保守も簡単だと思います。
問題は、きちんと書かれたサーバー側のテンプレートと、不適切に書かれたアドホッククライアント側のHTML生成を比較していることだと思います。もちろん、正しく記述されたコードは、読み取り、保守、およびトレースが簡単です。
クライアント側のコードを「HTMLの山」と呼びますが、もちろん、生成される場所はどこでも同じHTMLです。 「マウンド」はコードの大きな塊です。
クライアント側のテンプレートライブラリはたくさんあります。これらはサーバー側のものと同様に機能します。どちらを優先するかについては、パフォーマンスのトレードオフは複雑ですが、JSONは通常、HTMLに比べてコンパクトであり、テンプレートをクライアントに置くことでmayサーバー呼び出しを排除します。一方、クライアントではJSが無効になっているか、速度が遅すぎて実用的でない場合があるため、ターゲットオーディエンスにも依存します。全体として、アプローチはかなり似ていると思います。最大の要因は、対象読者のブラウザー機能です。
しかし、それはあなたが何をしているのか、サーバー環境よりもJSを好むかどうか、どのテンプレートソリューションを好むかに依存します。
クライアント側のテンプレートを使用する傾向があります。極端な場合、サーバーがすべてのクライアント側のレンダリングを行いながら、たとえばJSON形式のRESTful APIのみを提供する場合があります。このアプローチの利点は、JSコードとテンプレートが静的なリソースであり、CDNを介してキャッシュ、プロキシ、および配布できることです。サーバーサイドで生成されたダイナミックHTMLを使用している場合は、これを行うことができません。また、RESTful APIからのデータのみを軽量形式で返すと、サーバー側のリソースがはるかに少なくなり、応答が速くなります。また、軽量であるため、ネットワーク転送が少なくなり、高速になります。このようにして、3Gなどの低速な接続でも非常に応答性の高い低遅延アプリケーションを実現できます。したがって、このアプローチはモバイルページやアプリケーションで人気があります。
JSテンプレートを実装する多数のライブラリがあり、人気のあるものの1つは Pure 、 Mustache および dust.js です。後でLinkedInによって使用され、彼らは彼らの記事で利点を説明しました"JSPをほこりに残す：LinkedInをdust.jsクライアント側テンプレートに移動する"。
クライアントでHTMLを生成する利点は、レンダリングの作業を各クライアントにオフロードすることです。これは、応答を待機しているアイドル状態にあります。より多くのサーバーリソースを解放して、JSONデータと静的コンテンツ（HTML、JS、CSS）のみを配信します。
JavaScriptを使用してHTMLのみを生成するWebアプリを作成します。サーバーヒットの87％はJSONデータであり、静的コンテンツは通常、一度ブラウザーのキャッシュから読み込まれます。
しかし、SEOが必要な場合は、少なくとも簡単には使用できません。または、JavaScriptが無効になっているユーザーをターゲットに設定しているが、これがまだYouTube、Twitter、Facebook、Gmailなどと関連があるかどうかは不明です。
ポートレットを使用しているため、jqueryでhtmlコードを生成しています。jspコードの実行後、htmlコードでループを作成する必要があります。これは、Java forいくつかのJavaScriptコードでループします。そのため、JavaScript配列でJava arraylistをレンダリングし、文字列を使用してHTMLを生成しています。
私たちは単一ページのアプリ（ala Google Mail）を構築しており、文字通りnoアプリ内にHTMLのサーバー側生成があります。代わりに、Backbone.jsを使用してクライアント側を構成し、ハンドルバーを使用して、JSONをページに移動するテンプレートにレンダリングします。それは確かに非常にうまく機能し、私たちはそれを使用する最初のアプリの終わりに近づいており、将来さらに大きなプロジェクトに取り組みます。
サーバーがデータを永続化し、クエリ結果を返すためだけに使用されるあらゆる種類のファットクライアントは、JavaScriptでHTMLを生成する必要があるときのポスターの子です。優れたテンプレートエンジンを使用して、クリーンで簡単にするようにしてください。
動的なページの読み込みに関しては、「JQuery AJAX Cloud！」マジックの背後で、2つの可能性のあることが起こっていることを理解する必要があります。
- 要素のコードがdiv（不良）に挿入されている、または
- コンテンツはiframeに読み込まれています（より良いですが、同じではありません...）
元の質問については、サーバーに保存されているXMLまたはJSONデータを読み取るWebアプリケーションを作成しているときにJavaScriptを介してHTMLコンテンツを作成するだけで、多くの変更が加えられます。
Javascriptを使用してページに静的コンテンツをロードすることはあまり意味がありません。正しくロードされないか、クライアントがそれを無効にする可能性があるためです（「厄介な広告を撮ってください！」）。さらに、醜いdocument.write()またはdocument.createElement()のチェーンの内部に埋め込まれたHTMLコンテンツを変更することは非常に難しくなります。
だから、あなたは正しいです。生のHTMLを入力するか、動的なコンテンツが必要な場合は、サーバー側のスクリプトを使用して必要なものを出力します。 JavaScriptを使用してHTMLを挿入するのは、サイトがインターネット接続なしで機能することを意図している場合、または同様の場合のみです。
最後に、xmlhttprequests、er、AJAXをWebサイトに実装する場合、おそらくデータを（XMLなどの）データ形式で格納し、ロードして、それに応じて出力するのが最も安全な方法です。クライアントで。 document.writeおよびelement.innerHTMLは、コンテンツを操作するための最良の方法ではありません。将来、頭痛の種になる可能性があります（このスクリプトが実行されないのはなぜですか？壊れた<i>タグはすべてイタリック体です！等。）。
そのことについての私のマントラは、そのマークアップが簡単で誰も気にしないときです。
また、両方を活用して、マークアップを気にするのがあまりにも難しく、DOMツリーに焦点を当てたい制限を定義することもできます。たとえば、動的な行があるフォーム（「別の添付ファイルを追加する」など）は、おそらくHTMLのフォーム、「行を追加」ボタン、および送信ボタンが必要です...おそらく生成したくないでしょう。サーバー側の言語などを使用したHTML。
もう1つの経験則は、再利用性です。ソリューションをクライアント側の他の問題に適用できる場合は、それをjsにカプセル化します。