複雑なJavaScript UIの開発アプローチ[終了]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 6年前に閉鎖されました。 複雑なクライアントサイドJavaScriptの開発に関するさまざまなアプローチの状況とベストプラクティスを理解しようとしています。 このクラスのアプリケーション、おそらく重いAJAXまたはRIA（ただし、Flash / Silverlightなどのプラグインではない）に何をラベル付けするのかわかりません。これらの特性を備えたWebアプリを参照しています。 JavaScriptでリッチ/ネイティブデスクトップUXをエミュレートします サーバーをデータAPI（JSON / Html-Templates）として使用して、クライアント側JSのほとんど/すべての動作を含みます。 これは、UIレンダリングにWebサーバーを使用して、ページ更新モデルですべてのHTMLを生成するのとは対照的です。 以下に例を示します。 Googleドキュメント/ Gmail マインドマイスター ピボットトラッカー HTML5に進むと、このスタイルのRIA開発が、重いJavaScriptを使用して、競争するためにますます一般的かつ必要になっていることがわかります。 質問：では、これらの種類の重いJS開発の管理に関して浮上している一般的なアプローチは何ですか？ アプリの機能が大きくなるにつれて、クライアント側のコードは非常に複雑になります。生のJSを使用して複数のチームにまたがって開発作業をスケーリングする際に問題が発生します（または、私はそれを聞いており、信じることができます）。 Googleは、高レベル言語（Java）からJSにコンパイルするGWTを構築し、高レベル言語にある既存の開発インフラストラクチャ（Eclipse、強力な型付け、リファクタリングツール）に加えて、ブラウザの互換性を抽象化することで問題に取り組みました。開発者から離れた他の問題。 同様のことを行うC＃用のScript＃など、他のツールもあります。これはすべて、JSをIL（中間言語）の役割にします。すなわち。「あなたは本当にその「低レベル言語」で書くことはありません。」 しかし、この「JSにコンパイル」が唯一のアプローチではありません。GWTが支配的なアプローチであることは明らかではありません...または実際にそれになるでしょう。 リッチクライアントJavaScriptを使用して人々は何をしていますか？いくつかのオリエンテーションに関する質問： ほとんどのショップはJSを手動で作成していますか（jQueryなどのライブラリの上）。 または、明確なベストプラクティスが明らかになっていない、多くの異なるアプローチがありますか？ ほとんどのショップは、RIAスケールの開発を避けて、よりシンプルな開発者向けのサーバーサイド/ページ再描画モデルを支持していますか？もしそうなら、これは続くでしょうか？ JSへのコンパイルは、おそらく新たな将来のトレンドですか？それとも、これは間違っているのでしょうか？ クライアントJSの複雑さとリファクタリングをどのように管理していますか？ チーム間の作業のモジュール化と分散？ MVC / MVPなどのクライアント側パターンの適用、実施、テスト では、このJavaScriptとHTML5のこの重い未来の新しいトレンドはどのようなものでしょうか？ ありがとう！