複雑なJavaScript UIへのDevアプローチ
複雑なクライアント側JavaScriptの開発に関するさまざまなアプローチとベストプラクティスの状況を理解しようとしています。
重いAJAXまたは[〜＃〜] ria [〜＃〜]（ただし、Flash/Silverlightなどのプラグインではない） ）。私はこれらの特徴を備えたウェブアプリについて言及しています：
- JavaScriptでリッチ/ネイティブデスクトップUXをエミュレートする
- サーバーをデータAPI（JSON/Html-Templates）として使用して、クライアント側JSのほとんど/すべての動作を含みます。
これは、UIレンダリングにWebサーバーを使用して、すべてのHTMLをページ更新モデルで生成するのとは対照的です。
次に例を示します。
- Googleドキュメント/ Gmail
- マインドマイスター
- ピボタルトラッカー
HTML5に進むにつれ、JavaScriptを多用したこのスタイルのRIA開発が、ますます一般的になり、競争に必要になることがわかります。
質問：では、このような重いJS開発の管理に関して浮上している一般的なアプローチは何ですか？
アプリの機能が増えるにつれて、クライアント側のコードはひどく複雑になります。未加工のJSを使用する複数のチームにまたがる開発作業のスケーリングに問題があります（または私はそう聞いたので、信じられます）。
Googleは、より高いレベルの言語（Java）からJSにコンパイルするGWTを構築することで問題に取り組みました。開発者から離れた他の問題。
同様のことを行うC＃用のScript＃などの他のツールがあります。これにより、JSはIL（Intermediate Language）の役割をより果たすようになります。すなわち。 「あなたは本当にその「低水準言語」で実際に書くことはもうありません。」
しかし、この「JSへのコンパイル」が唯一のアプローチではありません。 GWTが主要なアプローチであることは明らかではありません。
リッチクライアントJavaScriptで何をしているのですか？方向付けに関するいくつかの質問：
- ほとんどのショップはJSを手動で作成していますか（jQueryなどのライブラリの上に）？
- または、明確なベストプラクティスが出現していない、多くの異なるアプローチがありますか？
- ほとんどのショップは、RIA規模の開発を避けて、開発者のサーバー側/ページ再描画モデルを単純化していますか？もしそうなら、これは続きますか？
- JSにコンパイルすることは、おそらく新たな将来の傾向ですか？それとも、これは間違っていますか？
- クライアントJSの複雑さとリファクタリングをどのように管理しますか？
- チーム間の作業のモジュール化と分散？
- MVC/MVPなどのクライアント側パターンのアプリケーション、適用、テスト。
つまり、私たちのJavaScriptとHTML5のこの重い未来における新たなトレンドは何ですか？
ありがとう！
私が目にするほとんどのWebアプリ（および私が話をしたWeb開発者）は、この方向に進んでおり、jQueryをベースとして使用しています。
GWT（および類似のマルチレベル言語）の背後にある全体的な理由は、JavaScriptは「本物のプログラマ」が使用するには不安定すぎたり、あまりにも壊れたり、あまりにも変更可能であるためです。ただし、フレーク/壊れやすい/変更可能なビットを処理するフレームワークがある場合は、その複雑なレイヤーを追加する理由はありません。
私の意見だけ…
GWTは危険だと思います。それを使用することに決めたら、あなたはそれにこだわっています。基本的には、マークアップ、DOM、CSSのいくつかの側面を実行環境として扱うことを意味します。クライアントコードがますます高度になるにつれて、手動で記述されたJavaScriptとGWTを混在させることは非常に困難になっています。 GWTにはネイティブメソッドがありますが、適用可能性の点で非常に制限されています。これは大きなトレードオフであり、大きな賭けです。
Googleは、適切なサーバー側統合を備えた非常に高速なXプラットフォーム実行環境としてGWTを販売しようとしています。しかし、他の人がすでに指摘したように、もはやそうではありません-JQueryとYUIは、高速ではないにしても同じくらい高速です。また、ページを手動で組み立てると、ページのプロファイルと最適化がはるかに簡単になるため、CSS、マークアップ、JavaScriptを完全に制御できます。
GWTは基盤となるプラットフォームをユーザーから隠そうとしますが、これは実際には間違った方法である可能性があります。多くのいわゆるコンポーネントWebフレームワークでも同じことが行われました。 ELとカスタムタグがスローされた、あいまいなXML派生コードを書くことになっていた。ページは遅く、バグが多く、完全にメンテナンスできませんでした。
現在のプロジェクトでは、低レベルのアクションベースのフレームワークであるStripesを使用し、クライアント側でJQueryを使用しています。パズルのすべてのピースを明確に見れば、Ajaxを実行するのは非常に簡単です。データを操作するサーバー側のコードを次に示します。これがクライアント側のコードです。データを取得したり、ページで物事を起こしたりするためのものです。ここにあなたのCSS、ここにあなたのマークアップ、これがあなたのテンプレートです-すべてがクリーンで分離されています。簡単に拡張可能、ハッキング可能、調整可能、デバッグ可能。大好きです。
スピードとシンプルさに対する姿勢がJQueryを愛しています。モジュール性と包括的なウィジェットのためのYUI3が大好きです。ブラウザ間で一貫性を持たせるために、YUI CSSが大好きです。良い部品のJavaScriptが大好きです。私はJava仕事を得るために私を愛しています。
キスだけで大丈夫！
これを「シングルページアプリケーション」と呼んでいます。
これは新しい環境であり、ルールはまだ完全に記述されていません。私は昨年（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がユニットテストを必要とするほど複雑である時期がすでに来ていると思います。これを可能にするアーキテクチャー/コードとともに。
ただし、複雑なサーバー側のアプリとは異なり、複雑なクライアント側のアプリの大部分にはユニットテストがまったくない（ここではSeleniumのテスト、実際のユニットテストについて話しているのではない）ことに私が直感します。
次の新たなトレンドは、単体テスト（および単体テスト可能なコード）の導入だと思います。ユニットテストされていないJavaScriptを適度に使用してプロジェクトを完了したところで、それが最後になることを願っています。