JavascriptでUIを100％実行し、APIを介してデータを提供することをお勧めしますか？

私の主な仕事はHTMLアプリケーションの作成です。それは、編集可能なグリッドビュー、テキストボックス、ドロップダウンなど、多くの内部でCRUDタイプのアプリケーションを内部で使用することを意味します。現在、ASP.NET Webフォームを使用しています。あなたが必要なものを得るためにフープを飛び越えなければなりません。天井から垂れ下がって炎を放つフープ。

だから、すべてのUIをJavaScript側に移動することはおそらく良い考えだろうかと思っています。特にニーズに合わせて調整された強力な再利用可能なコントロールを開発し、サーバーとのみデータを交換します。はい、私は「コントロール」（別名「ウィジェット」）パラダイムが好きで、そのようなアプリケーションに非常に適しています。したがって、サーバー側では、現在のASPXマークアップと同様の基本的なレイアウトがまだありますが、クライアントに送信されるのは1回だけであり、Javascript部分が後続のすべてのUI更新を処理します。

問題は、私がこれをやったことがなく、誰もこれをしているのを見たことがないので、問題がどうなるかわかりません。特に、私は心配しています：

• まだパフォーマンス。ベンチマークでは、現在、ブラウザがAJAX更新後にページのほとんどを再レンダリングしようとするときに、主な遅延がクライアント側にあることが示されています。ASP.NET webformsで生成されたマークアップは、「web」という言葉に新しい意味を与えます。また、豊富なDevexpressコントロールは、その上に独自のJavascript複雑さのレイヤーを追加します。しかし、JavaScript側で必要なすべての変更を再計算し、更新する必要があるものだけを更新する方が速いでしょうか？いくつかの編集可能なグリッドビュー、多数のテキストボックス、それぞれに50万個のフィルター可能なアイテムが含まれるドロップダウンなどがあるフォームについて話していることに注意してください。
• 開発のしやすさ。Javascriptはもっと多くなり、おそらくページのHTMLマークアップと混ざります。それまたは何らかの種類の新しいビューエンジンを作成する必要があります。JavascriptのIntellisenseはC＃コードよりもはるかに悪く、Javascriptの動的な性質のため、はるかに良くなることは期待できません。コーディングの慣行により少し改善できますが、それほど改善することはできません。また、ほとんどの開発者は主にC＃開発者であるため、ある程度の学習曲線と最初の間違いがあります。
• セキュリティ。多くのセキュリティチェックを2回（サーバー側とUI側）行う必要があり、データ処理サーバー側にはさらに多くのチェックを含める必要があります。現在、サーバー側でテキストボックスを読み取り専用に設定した場合、その値がクライアントのラウンドトリップを通じて変わらないことに依存できます。フレームワークには、それを保証するのに十分なコードが既にあります（ビューステートの暗号化により）。データのみのアプローチでは、すべてを手動で確認する必要があるため、難しくなります。一方、心配する必要があるのはデータだけなので、セキュリティホールを見つけるのは簡単です。

全体として、これは問題を解決するのか、それとも悪化させるのか？誰かがこれを試みたことがありますか？その結果はどうでしたか？この種の取り組みに役立つフレームワークはありますか（jQueryと道徳的な同等物は別として）？

Linkedinはモバイルサイトでこれを行います（http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobileパート4を参照）。これは明らかに、パフォーマンスの観点。

ただし、さまざまな理由から、同じことを避けることをお勧めします。

1つ目は保守性です。C＃/ ASP.netは、サーバー側のフレームワークであるため、クライアントに依存しませんが、Javascriptはそうではありません（jQueryのようなフレームワークを使用しても、ブラウザ間の互換性は100％になりません） 、将来を保証するものではありません）。また、大規模なサイトを構築する場合に絶対に考慮する必要がある動的なアプリケーションよりも、静的に型付けされたアプリケーションの機能を検証する方が簡単だと思います。

2つ目は、Webサイト全体を実行するのに必要な種類の複雑な純粋なjavascriptアプリケーションを構築する（そしてそれを喜んで）他の人を見つけるのが難しいことです（比較的見つけやすいです）。 NETプログラマー）。これはあなたの直接の関心事ではないかもしれませんが、長期的な観点から考えることは確かです。

3番目の問題は、クライアントの互換性です。公共向けのWebサイトを構築する場合、ネットの合理的な部分ではまだJSが有効になっていないことに注意してください（さまざまな理由により）。 JS主導のWebサイトに切り替えて、ユーザーベースの

あなたの箇条書きの懸念について：

• 私はセキュリティの側面についてあまり心配しません、セキュリティが必要なときにパラダイムを混合してサーバー側の処理を行うことができない理由はありません（HTMLを返すどこかにビューレンダリングコードがあります、必要に応じて、代わりにAJAX呼び出しを起動させることができない理由はありません）。

• 開発のしやすさもあまり心配ではありません。私の意見では、JS開発に使用できる非常に優れたツールがあります。（たとえば、JetBrains WebStormを試してください）。

• JSビューエンジンのパフォーマンスは、ほとんどの場合（ここでも、私の経験では）まったく問題ありません。日常的に頻繁に使用しています。私が提案するのは、knockout.jsなどのようなより重いフレームワークを避け、代わりにJon Resigのマイクロテンプレートエンジンのようなものに向かうことです。これにより、高速で信頼性の高い方法でサポートコードをプラグインできます。

もし私があなただったら、この切り替えの背後にある理由を実際に調べます。.NETを効果的に活用しておらず、ゲームをアップする必要があるだけかもしれません。WebFormsはすぐに使用できる特に遅いフレームワークではないため、使用しているサードパーティライブラリの一部レンダリングが遅くなっています。

負荷テストとプロファイリングツールを使用してアプリケーションのパフォーマンスプロファイルを実行してみて、より過激なソリューションに多大な時間と労力を費やす前にボトルネックがどこにあるかを確認してください。あなたの遅さの犯人！

そのようにしたい場合は、ExtJSを使用してください。車輪を再発明しないでください。しかし、準備してください、これは完全なパラダイム変更を意味します。あなたのHTMLスキルはほとんど使われていません。AJAXはどこでも、サーバーはほとんどAJAX APIを提供します。あなたはこれまでよりもずっと多くのjavascriptを書くので、javascriptに本当に合っていることを確認してください。

私が所属するチームは、2008年後半にExtJSに移行することにしました。その時点で、フロントエンドの問題に悩まされていた200.000行のPHPアプリがありました。ハンドロールされたフォームコントロールフレームワークが非常に悪く、ページのセクションを読み込むためにiframeを頻繁に使用していたため（私たちの状況は2005年に遡り、チームは認識していなかったため、初期のajaxの）。とにかくコードをリファクタリングする必要があったため、これにより、コードベースを主にクライアント側に大幅に再設計することを決定しやすくなりました。

現在、アプリは300.000行で、そのうち60.000行はextjsコードであり、機能の約3/4がExtJSに移行されています。extjsコードはすべて単一ページのアプリですが、iframe内にいくつかのレガシーフォームがまだ埋め込まれています。最初にナビゲーションコンテナに移植し、次にさまざまな機能領域を少しずつ移行しました。このアプローチにより、extjsの移行を通常の機能開発プロセスにスリップストリームすることができました。

• 性能

  ExtJSコードは、レガシーコードよりもはるかに高速であることが証明されました。もちろん、古いコードはパフォーマンスの面では本当に悪いものでしたが、それでも結果に満足しています。UIコードはすべて静的javascriptであるため、非常に適切にキャッシュされます（CDNにスローする計画段階です）。サーバーはフロントエンドレンダリングに関与しないため、そこでの作業負荷が軽減されます。また、ExtJSがUIのライフサイクル（遅延レンダリング、不可視のUI要素の簡単なアンロード）の多くの制御を提供するのに役立ちます。通常、コードがブートストラップされると（オンデマンドロードアーキテクチャ）、画面のロード時間のほとんどは、データをフェッチするためのWebサービス呼び出しに費やされます。ExtJSグリッドは、特にスクロール時に表示行をレンダリングするためにバッファービューを使用する場合、非常に高速です。

• 開発のしやすさ

  正直に言うと、これは混合バッグです。ExtJSはDSLであり、伝統的な意味でのWeb開発ではありません。開発者がフレームワークのAPIを実際に習得するのに長い時間がかかりました。他のクライアント側フレームワークでは、この曲線がそれほど急ではないと思います。チームの全員が「シニア」javascript開発者でなければなりません（経験則として、クロックフォードの本には秘密はないはずです）。クライアント側の専門知識があなたが思うほど広く普及しておらず、extjsの専門知識がほとんどないため（私たちがいるベルギーでは）、新しい開発者のブートストラップの問題に苦しんでいます。

  一方で、あなたが最新の状態になったら、開発者の経験は非常に素晴らしいです。ExtJSは非常に強力であるため、溝にいる場合は、驚くべき画面を非常にすばやく作成できます。IDEに関しては、ExtJSコードについて十分な能力があることがわかったPHPStormを使用します。

• セキュリティ

  セキュリティは、クライアント側UIを実行する主な理由の1つです。理由は簡単です：攻撃対象領域の削減。ExtJSコードで使用されるWebサービスAPIは、サーバー側のUIレイヤーよりもはるかに小さな攻撃対象領域です。OWASPのASVSは、サーバー上のすべての入力が正しいかどうかを検証してから使用することを指定しています。Webサービスアーキテクチャでは、入力検証をいつ、どのように行うかは明白で簡単です。また、クライアント側のUIアーキテクチャのセキュリティについても簡単に推論できます。エンコードからHTMLへの移行を免れなかったため、XSSの問題にはまだ苦労していますが、全体的には、古いコードベースよりもセキュリティに関してはるかに優れています。ExtJSを使用すると、フォームフィールドのサーバー側の検証を簡単に実行できるため、コードを2回記述する必要がなくなります。

スクリプトレスユーザーをサポートしない余裕があり、検索エンジンがあなたに関係ない場合、それは完全に実行可能なアプローチです。長所と短所の簡単な要約を次に示します。

長所：

• 1か所ですべて（javascript）
• マークアップではなくサーバーからデータをロードできます。適切に行えば、多くの帯域幅を節約できます
• レスポンシブアプリケーションを取得するのは簡単です（ネットワーク遅延はまだありますが、ユーザーの入力に対する初期応答は速くなります）
• Webサーバーは、HTMLをレンダリングしたり、テンプレートを展開したりする必要はありません（つまり、処理の労力はサーバーからクライアントに移動されます）

短所：

• すべてがJavaScriptである必要があります（問題になる場合もあれば、そうでない場合もあります）
• 重要なロジックをサーバー上で複製する必要があります
• 状態をクライアントとサーバーで維持し、両方の間で同期する必要があります
• セキュリティを正しくすることが難しくなる可能性があります（悪意のあるユーザーがクライアント側のコードを操作する方法を検討してください）
• コードベースの大部分を公開します（サーバーで実行されるコードは外部から見ることができません）

個人的には、このルートに行くと、ASP.NET UpdatePanelsは正しい方法ではないと思います。既存のWebアプリケーションを部分的にアジャキシ化するのに最適ですが、AJAXを介してHTMLを送信するため、この方法で状態を管理するのは非常に困難です。静的なHTMLドキュメントだけを提供し、Javascriptテンプレートライブラリを使用してHTMLレンダリングを実行する方が良いでしょう。サーバーは動的HTMLをまったく提供せず、代わりにクライアントがサーバーに対してビジネスロジックレベルの呼び出しを行い、生データを受信します。

はい、できますが。

アプリケーションの重要な部分がJavascriptなしでも機能するように、適切な「劣化」があることを確認する必要があります。

これが、ほとんどのアプリ「HIJAX」スタイルを構築する方法です。

私のサイトはまだ初期段階ですが、これまでのところ100％js uiで十分です。フロントエンドに存在する唯一のサーバーロジックは、モデルマッピングとAjax URLです。サーバーには、UIについての知識がまったくありません。これは私にとって非常に簡単に管理できます。興味があるなら、ExtJS http://coffeedig.com/coffee/で書かれた私のサイトをチェックアウトできます。私のサイトには実際にはセキュリティ上の問題はありませんが、クライアントは簡単な検証によって通常のユーザーを支援します。悪意のあるユーザーが実際にサーバーにajaxを送信できるため、すべての「セキュリティ」ロジックがサーバーで実行されることを知っています。

あなたにとって最大の問題は、チームが慣れ親しんでいるものを完全に反転させようとしていることだと思います。急な学習曲線があるでしょう。最良のアプローチは、いくつかのjsフレームワークを試して、いくつかの単純な画面を作成して、その感覚をつかむことだと思います。