JSONの代わりに生成されたHTMLを返すことが悪い習慣であるのはなぜですか？またはそれは？

JQueryまたは他の同様のフレームワークを使用して、カスタムURL / WebサービスからHTMLコンテンツをロードするのは非常に簡単です。私はこのアプローチをこれまで何度も使用してきましたが、パフォーマンスは満足できるものでした。

しかし、すべての本、すべての専門家が、生成されたHTMLではなくJSONを使用するようにしています。HTMLよりもはるかに優れているのはなぜですか？

とても速いですか？
サーバーへの負荷は非常に少ないですか？

一方、生成されたHTMLを使用する理由はいくつかあります。

1. これは単純なマークアップであり、多くの場合、JSONよりもコンパクトであるか、実際にはJSONよりコンパクトです。
2. エラーが発生しにくいため、マークアップだけでコードはありません。
3. ほとんどの場合、プログラムの方が速くなります。これは、クライアントエンド用に個別にコードを記述する必要がないためです。

あなたはどちら側にいますか、そしてその理由は？

私は実際には両側です。

• JavaScript側で必要なのがデータの場合は、JSONを使用します
• JavaScript側で必要なのは、計算を行わないプレゼンテーションである場合、通常HTMLを使用します

HTMLを使用する主な利点は、ページ全体をAjaxリクエストから返されるもので置き換えたい場合です。

• JSでページの一部を再構築することは（かなり）難しい
• おそらくサーバー側にテンプレートエンジンがすでにあります。これは、最初にページを生成するために使用されていました...再利用しないのはなぜですか？

私は通常、少なくともサーバーでは、実際には「パフォーマンス」の側面を考慮していません。

• サーバーでHTMLの一部または一部のJSONを生成しても、それほど大きな違いはないでしょう。
• ネットワークを通過するもののサイズについて：まあ、おそらく数百KBのdata / htmlは使用しないでしょう...転送するものにgzipを使用すると、最大の違いが生まれます（HTMLを選択しないこと）およびJSON）
• ただし、考慮に入れることができる1つのことは、JSONデータからHTML （またはDOM構造）を再作成するためにクライアントで必要なリソースです。HTML の一部をページにプッシュすることと比較してください。 -）

最後に、間違いなく重要なことが1つあります。

• データをJSON +コードとして送信する新しいシステムを開発するのにどのくらいの時間がかかりますか？JSがHTMLとしてページに挿入するために必要なコード
• HTMLを返すだけでどのくらいかかりますか？また、既存のサーバー側コードの一部を再利用できる場合、どれくらいの時間がかかりますか？

そして別の答えに答えるには、ページの複数の部分を更新する必要がある場合でも、いくつかのHTML部分をグループ化する1つの大きな文字列内にそれらすべての部分を送信し、JSで関連部分を抽出する解決策/ハックがあります。

たとえば、次のような文字列を返すことができます。

<!-- MARKER_BEGIN_PART1 -->
here goes the html
code for part 1
<!-- MARKER_END_PART1 -->
<!-- MARKER_BEGIN_PART2 -->
here goes the html
code for part 2
<!-- MARKER_END_PART2 -->
<!-- MARKER_BEGIN_PART3 -->
here goes the json data
that will be used to build part 3
from the JS code
<!-- MARKER_END_PART3 -->

見た目はよくありませんが、それは間違いなく便利です（ほとんどの場合、HTMLデータが大きすぎてJSONにカプセル化できない場合に使用しました）。ページの一部のHTMLを送信しています。プレゼンテーションが必要で、データが必要な状況でJSONを送信しています...

...そして、それらを抽出するために、JSサブストリングメソッドがトリックを実行すると思います;-)

ここで述べた意見に主に同意します。私はそれらを次のように要約したかっただけです：

• クライアント側でHTMLを解析していくつかの計算を行う場合は、HTMLを送信することはお勧めしません。

• JSONをページのDOMツリーに組み込むだけの場合は、JSONを送信することはお勧めしません。

上手、

私はこのように物事を分離することを好むまれな人物の1人です。-サーバーはデータ（モデル）の配信を担当します。-クライアントはデータの表示（ビュー）と操作（モデル）を担当します。

したがって、サーバーはモデルの配信に焦点を合わせる必要があります（この場合、JSONの方が優れています）。これにより、柔軟なアプローチが可能になります。モデルのビューを変更する場合は、サーバーが同じデータを送信し続け、そのデータをビューに変更するクライアント、JavaScriptコンポーネントを変更するだけです。想像してみてください。モバイルデバイスとデスクトップアプリにデータを配信するサーバーがあるとします。

また、サーバーとクライアントのコードを同時に構築できるため、このアプローチにより生産性が向上します。jsからPHP / JAVA /などに切り替え続けると、フォーカスが失われることはありません。

一般に、私はほとんどの人がjsをマスターしていないのでサーバー側でできるだけ多くのことをすることを好むと思います。

基本的に、私はAngularに取り組んでいる人たちと同じ意見です。私の意見では、これはWebアプリの未来です。

追加したいと思った面白いものがあります。全画面表示を一度しか読み込まないアプリケーションを開発しました。それ以降は、ajaxのみを使用してサーバーに通信を戻します。1ページをロードするだけで十分でした（ここでの私の理由は重要ではありません）。興味深いのは、JavaScriptで操作するデータと、表示する部分的なビューを返す必要があるという点です。これを2つの別々のアクションメソッドへの2つの呼び出しに分割することもできましたが、もう少し楽しいものを使用することにしました。

見てみな：

public JsonResult MyJsonObject(string someData)
{
     return Json(new { SomeData = someData, PartialView = RenderPartialViewToString("JsonPartialView", null) }, JsonRequestBehavior.AllowGet);
}

あなたが尋ねるかもしれないRenderPartialViewToString（）とは何ですか？これは、ここのクールさの小さなナゲットです。

protected string RenderPartialViewToString(string viewName, object model)
{
     ViewData.Model = model;

     using (StringWriter sw = new StringWriter())
     {
          ViewEngineResult viewResult = ViewEngines.Engines.FindPartialView(ControllerContext, viewName);
          ViewContext viewContext = new ViewContext(ControllerContext, viewResult.View, ViewData, TempData, sw);
          viewResult.View.Render(viewContext, sw);

          return sw.GetStringBuilder().ToString();
     }
}

私はこれでパフォーマンステストを行っていないので、JsonResultの1つのアクションメソッドとParticalViewResultの1つを呼び出すよりも多少オーバーヘッドがかかるかどうかはわかりませんが、それでもかなりクールだと思いました。部分的なビューを文字列にシリアル化し、パラメーターの1つとしてJsonと共に送信します。次に、JQueryを使用してそのパラメーターを取得し、適切なDOMノードにスラップします:)

あなたが私のハイブリッドについてどう思うか教えてください！

応答でクライアント側の処理がそれ以上必要ない場合、私の意見ではHTMLで問題ありません。JSONを送信しても、クライアント側の処理を強制するだけです。

一方、すべての応答データを一度に使用したくない場合は、JSONを使用します。たとえば、一連の3つのチェーンされた選択があります。1つの選択された値によって、2番目の値の入力に使用される値が決まります。

IMV、それはデータのプレゼンテーションからデータを分離することのすべてですが、Pascalを使用しているため、その分離がクライアント/サーバーの境界を越えてのみ可能であるとは限りません。（サーバー上で）その分離がすでにあり、クライアントに何かを表示したいだけの場合、JSONを送り返してクライアントで後処理するか、または単にHTMLを送り返すかは、完全にニーズに依存します。一般的なケースでHTMLを送り返すのが「間違っている」と言うのは、IMVステートメントを完全に覆い隠すだけです。

JSONは非常に用途が広く軽量な形式です。クライアント側のテンプレートパーサーデータとして使用し始めたとき、その美しさを発見しました。説明したいのは、サーバー側でsmartyとビューを使用していた（サーバー負荷が高い）以前は、カスタムjquery関数をいくつか使用しており、クライアントブラウザーをテンプレートパーサーとして使用して、すべてのデータがクライアント側でレンダリングされます。サーバーのリソースを節約し、ブラウザは毎日JSエンジンを改善します。したがって、クライアント解析の速度は現在重要な問題ではありません。さらに、JSONオブジェクトは通常非常に小さいため、クライアント側のリソースを大量に消費しません。サーバーの負荷が非常に高いため、すべてのユーザーに対して遅いサイトではなく、遅いブラウザーを使用している一部のユーザーには遅いウェブサイトを使用することを好みます。

一方、サーバーから純粋なデータを送信すると、プレゼンテーションからデータを抽象化できるため、明日データを変更したり、データを別のサービスに統合したりする場合は、はるかに簡単です。

ちょうど私の2セント。

私の意見ではベストプラクティスであるクリーンな分離クライアントが必要な場合は、JavaScriptによってDOMを100％作成することは理にかなっています。UIを構築する方法をすべて知っているMVCベースのクライアントを構築する場合、ユーザーは1つのJavaScriptファイルを一度にダウンロードすると、クライアントにキャッシュされます。初期ロード後のすべてのリクエストはAjaxベースであり、データのみを返します。このアプローチは私が見つけた中で最もクリーンであり、プレゼンテーションのクリーンな独立したカプセル化を提供します。

サーバー側はデータの配信に焦点を合わせます。

したがって、明日、製品がページのデザインを完全に変更するように要求するとき、変更するのはDOMを作成するソースJSだけですが、既存のイベントハンドラーを再利用する可能性が高く、サーバーはプレゼンテーションから100％分離されているため気付かない

UIによっては、DOM内の2つ（またはそれ以上）の異なる要素を更新する必要がある場合があります。応答がHTMLの場合、それを解析して何がどこにあるのかを理解しますか？または、JSONハッシュを使用することもできます。

それを組み合わせて、htmlデータ付きのJSONを返すこともできます:)

{ 'dom_ele_1' : '<p>My HTML part 1</p>', 'dome_ele_2' : '<div>Your payment has been received</div>' }

HTMLには、タグ、スタイルシートなど、多くの冗長な表示されていないデータがあります。そのため、JSONデータと比較してHTMLサイズが大きくなり、ダウンロードとレンダリング時間が長くなり、新しいデータのレンダリングでブラウザーがビジー状態になります。

jsonの送信は通常、リストやツリービュー、オートコンプリートなどのサーバーからの情報を要求するJavaScriptウィジェットがある場合に行われます。これは、解析されてそのまま使用されるデータであるJSONを送信するときです。ただし、HTMLを表示するだけの場合は、サーバー側で生成してブラウザで表示するだけで済みます。ブラウザはinnerHTML = ""を使用してHTMLをdomに直接挿入するように最適化されているため、問題が発生することはありません。

それはデザインの構造に依存すると思います。JSONを使用することはHTMLよりも魅力的ですが、問題は簡単に維持できるようにそれをどのように処理するかです。

たとえば、サイト全体と同じhtml /スタイルを利用するリストページがある場合、グローバル関数を記述してHTMLのこれらの部分をフォーマットし、JSONオブジェクトを関数に渡すだけで済みます。

クライアント側で計算を実行する必要がない限り、ほとんどの場合、HTML応答で十分です。

状況によります。

JSONを回避することが不可欠な場合があります。たとえば、プログラマーがjsでのプログラミングに問題がある場合。

私の経験から、インラインJSONよりもajaxサービスを使用するほうがよいことがわかりました。

遅かれ早かれ、jsが問題になる