複雑なJavaScript UIの開発アプローチ[終了]

複雑なクライアントサイド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のこの重い未来の新しいトレンドはどのようなものでしょうか？

ありがとう！

私が見ているほとんどのWebアプリ（および私が話したWeb開発者）は、この方向に進んでおり、jQueryをベースとして使用しています。

GWT（および同様のマルチレベル言語）の背後にある全体的な理由は、JavaScriptが「本物のプログラマー」が使用するにはあまりにもゆるい/あまりにも壊れやすい/あまりにも変更可能であるということです。ただし、flakey / fragile / changeableビットを処理するフレームワークがある場合は、その複雑さを追加する理由はありません。

ただ私の意見…

GWTは危険だと思います。それを使用することに決めたら、あなたはそれで立ち往生しています。基本的に、マークアップ、DOM、CSSの一部を実行環境として扱うことを意味します。クライアントコードがますます高度になるにつれて、手動で記述されたJavaScriptとGWTを混在させることは非常に難しくなっています。GWTにはネイティブメソッドがありますが、適用可能な可能性の点でかなり制限されています。それは大きなトレードオフであり、大きな賭けです。

Googleは、適切なサーバーサイド統合を備えた非常に高速なXプラットフォーム実行環境としてGWTを販売しようとしています。しかし、他の人がすでに指摘したように、それはもはや事実ではありません-JQueryとYUIは、高速ではないにしても高速です。また、ページを手動でアセンブルすると、ページのプロファイリングと最適化がはるかに簡単になるため、CSS、マークアップ、JavaScriptを完全に制御できます。

GWTは、基盤となるプラットフォームをユーザーから隠そうとしますが、これは実際には間違った方法である可能性があります。いわゆるコンポーネントWebフレームワークの多くが同じことをしました。ELとカスタムタグをスローして、あいまいなXML派生コードを記述することになっています。出力は、粗雑なJavaScriptの小さな断片が至る所に散らばった、不完全な形式のHTMLの混乱です。ページは遅く、バグが多く、まったくメンテナンスできませんでした。

現在のプロジェクトでは、低レベルのアクションベースのフレームワークであるStripesと、クライアント側のJQueryを使用しています。パズルのすべてのピースを明確に見ると、Ajaxを実行するのは非常に簡単です。データを操作するサーバー側のコードを次に示します。クライアント側のコードは次のとおりです。データを取得したり、ページ上で何かを実行したりするためです。これがCSS、マークアップ、テンプレートです。すべてがクリーンで分離されています。簡単に拡張可能、ハッキング可能、調整可能、デバッグ可能。大好きです。

JQueryは、スピードとシンプルさに対する姿勢が大好きです。モジュール性と包括的なウィジェットのためにYUI3が大好きです。ブラウザ間で一貫性を提供してくれるYUI CSSが大好きです。良い部品のためのJavaScriptが大好きです。仕事を終わらせてくれるJavaが大好きです。

KISSだけで大丈夫です！

これらは「シングルページアプリケーション」と呼ばれています。

これは新しい環境であり、ルールはまだ完全には書かれていません。私は昨年（2010年）比較的大きな単一ページのアプリケーションに取り組んでおり、これらは私たちが使用したツールです。

バックエンドはJavaであり、サーブレットを使用してJSONサービスを提供し、最終的に準備された注文を送信するためにページが使用されました。このサービスは、いくつかの検証手順と価格設定にも使用されました。

フロントエンドコードはjavascriptでした。jQueryを使用してページ要素を操作し、Pureをテンプレート化し、RequireJsを使用してコードをモジュールに分割しました。（RequireJsのビルドツールは、より最適なダウンロードを提供するために使用されました。）

私たちが使用して我々のテストを書いたqUnitを、そして使用JUnitテストだったhtmlunitを各qUnitテストを実行するようにし、その後、結果の出力をこすり、そして渡したりqUnitパスに基づいて/ステータスをフェイル。これらはバックエンドのjUnitテストに追加され、Hudson / Jenkinsを使用してciに組み込まれました。

私は、Ext JSの上に構築されたこのようなアプリに取り組んでいます。アプリはモジュール式に構成されています。さまざまなモジュールが自己完結型コンポーネントとして実装されており、Extコンポーネント階層から削除されると自動的にクリーンアップされます。オンデマンドローダーは、追加のコンポーネントが必要になる直前にロードします（1つのjsファイル= 1つのコンポーネント）。

私は、このアプローチがそれほど難しくないことを発見しました。私が遭遇した唯一の本当の制限は、IEで同時にツリー内のDOM要素が多すぎることに関連しています。そこでの解決策は、アプリケーションの隠れた部分を戦略的にアンロードすることです。すべてのDOM操作はExtコンポーネント階層を介して行われるため、DOMはほぼ完全に抽象化され、開発は簡単です。

個人的には、jQueryなどのフレームワークは、異なるブラウザー間でのバリエーションに対処するだけでなく、それらの違いを隠してコードにノイズを追加しないようにするためにも不可欠だと思います。GWT、Websharperなどのツールはさらにそれを活用し、間違いなく場所を持っていますが、ほとんどの場合、それは単なる間接的な追加レイヤーに過ぎないのでしょうか。

誰も言及していないことに私が驚いたのは、単体テストです。複雑なサーバーサイドアプリには自動化された単体テストが必要であることは現在一般的に受け入れられており、RIAアプリのJSが単体テストを必要とするほど複雑であり、それを可能にするアーキテクチャ/コードがすでに登場していると思います。

ただし、複雑なサーバー側アプリとは異なり、私が見たり聞いたりすることに基づいた私の直感は、大部分の複雑なクライアント側アプリにはユニットテストがないことです（ここでは、セレンテスト、実際のユニットテストについては話していません）。

次の新しいトレンドは、単体テスト（および単体テスト可能なコード）の導入になると思います。ユニットテストされていないJavaScriptを適度に使用してプロジェクトを完了したので、それが最後になることを望んでいます。