JavaScriptでUIを100％実行し、APIを介してデータを提供することは良い考えですか？

Question

私の主な仕事はHTMLアプリケーションの作成です。つまり、多くの編集可能なグリッドビュー、テキストボックス、ドロップダウンなどを備えた内部で使用されるCRUDタイプのアプリケーションを意味します。現在、私たちはASP.NET Webフォームを使用しています。必要なものを取得するには、フープをジャンプする必要があります。天井から吊り下げられたフープ。

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

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

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

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

Ed James · Answer

Linkedinはモバイルサイトに対してこれを行い（ http://engineering.linkedin.com/nodejs/blazing-fast-nodejs-10-performance-tips-linkedin-mobile パート4を参照）、明らかにそれはパフォーマンスの観点から彼らにとって非常に有益でした。

ただし、さまざまな理由から、同じことを行わないことをお勧めします。

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

2つ目は、ウェブサイト全体の実行に必要な種類の複雑さのピュアJavaScriptアプリケーションを構築できる（そして喜んで）他の人を見つけるのが難しいことです（比較的簡単に見つけることができます）。 NETプログラマー）。これは直接の懸念ではないかもしれませんが、長期的な観点から考えると確かに問題になります。

3番目の問題は、クライアントの互換性です。公開Webサイトを構築している場合は、ネットの妥当な部分で（さまざまな理由により）JSがまだ有効になっていないことを覚えておいてください。そのため、大きな部分を除外しないようにしてください。 JS駆動のWebサイトに切り替えることで、ユーザーベースを強化します。

あなたの弾丸の心配に関しては：

セキュリティの側面についてはあまり心配しません。セキュリティが必要な場合にパラダイムを混在させてサーバー側の処理を実行できない理由はありません（HTMLを返す場所にビューレンダリングコードを配置します）、これをAJAXを呼び出す）だけで起動できない理由はありません。
開発の容易さもあまり問題ではありません。私の意見では、JS開発には非常に優れたツールが利用できます。慣れているため、VisualStudioにボックス化するだけではありません。（たとえば、JetBrains WebStormを試してください）。
JSビューエンジンのパフォーマンスは、ほとんどの場合（ここでも、私の経験では）まったく問題ありませんが、日常的に頻繁に使用しています。私が提案するのは、knockout.jsなどのより重いフレームワークを避け、代わりにJon Resigのマイクロテンプレートエンジンのようなものに向かうことです。このようにして、高速で信頼できると確信できる方法でサポートコードをプラグインできます。

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

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

user281377 · Answer

そのようにしたい場合は ExtJS を使用し、ホイールを再発明しないでください。しかし、準備してください。これは完全なパラダイムの変化を意味します。 HTMLのスキルはほとんど時代遅れです。 AJAXどこでも、サーバーは主にAJAX APIを提供します。これまでよりもはるかに多くのJavaScriptを書くので、JavaScriptに本当に適していることを確認してください。

Joeri Sebrechts · Answer

私がいるチームは、2008年後半にExtJSに移行することを決定しました。その時点で、200.000行PHPフロントエンドの問題が発生したアプリがありました。本当に悪いハンドロールフォームコントロールフレームワークがあり、ページのセクションを読み込むためにiframeを頻繁に使用していました（2005年に遡るビジュアルアーキテクチャであり、チームは早い段階でajaxを認識していませんでした）。とにかくコードをリファクタリングするため、これにより、コードベースが主にクライアント側になるように大幅に再設計することが容易になりました。

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

パフォーマンス

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

正直なところ、これは混合バッグです。 ExtJSはDSLであり、従来の意味でのWeb開発ではありません。開発者が実際にフレームワークのAPIを学ぶのに長い時間がかかりました。他のクライアント側のフレームワークでは、この曲線がそれほど急ではないと思います。チームの全員が「シニア」のJavaScript開発者である必要があります（経験則として、 crockfordの本は秘密を保持するべきではありません）。クライアント側の専門知識は思ったほど広くなく、extjsの専門知識はほとんどない（私たちがいるベルギーでは）ため、新しい開発者のブートストラップの問題に悩まされています。

一方、あなたがすぐに慣れると、開発経験はとてもいいです。 ExtJSは非常に強力であるため、溝にいる場合は素晴らしい画面をすばやく作成できます。 IDEに関しては、PHPStormを使用しています。これは、ExtJSコードに十分対応できることがわかっています。
安全保障

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

tdammers · Answer

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

長所：

すべてを1か所に（JavaScript）
マークアップではなく、サーバーからデータを読み込むことができます。これにより、正しく実行すると帯域幅を大幅に節約できます
応答性の高いアプリケーションを簡単に取得できます（ネットワーク待ち時間はまだありますが、ユーザーの入力に対する最初の応答が速くなります）
webサーバーはHTMLをレンダリングしたりテンプレートを展開したりする必要はありません（つまり、処理の労力はサーバーからクライアントに移されます）。

短所：

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

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

Darknight · Answer

はい、できますが..

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

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

pllee · Answer

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

あなたにとっての最大の問題は、あなたがチームが慣れていることを完全に逆転させようとしていることだと思います。急な学習曲線が存在するでしょう。いくつかのjsフレームワークを試して、簡単な画面をいくつか書いて感じをつかむのが最善の方法だと思います。