4

私のチームはより多くの Java 担当者で構成されており、JavaScript の経験は限られています。この質問が何度か聞かれたことは承知していますが、クライアント側のテクノロジに関する私の経験は非常に限られているため、事実を正しく理解するためにいくつか明確にする必要があります。純粋な JavaScript フレームワークの代わりに GWT を使用してソリューションを構築することにしました (より多くの Java 経験がある場合)。

これらは私の決断を裏付ける事実でした。

  • 100% Java で書かれています
  • 基本的な Java スキルが必要です (Java EE ではなく Java SE)。
  • OOPHM – アウト プロセス ホスト モード – ブラウザーとバージョンを定義します。ブラウザの互換性はもはや私たちの問題ではありません
  • デバッグ – IDE のデバッガーを使用して、GWT アプリを他の Java アプリケーションと同じようにデバッグします。
  • 最適化された JavaScript - GWT は、ユーザーよりも高速でコンパクトな JavaScript を記述します。

しかし、私のアプリケーション機能の一部は、外部の js ライブラリを使用する必要があります。たとえば、特定のページにいくつかのものを描画するために、特定のjsライブラリを利用する必要があるとしましょう。(実際には、dojos で作成された js ファイル)。

  1. 上記の要件は GWT で対応できますか?
  2. GWT を使用するという決定は賢明だと思いますか、それとも他に推奨事項はありますか?
  3. 私たちは、sencha gxt が最高のウィジェット ライブラリを持っていることを発見しました (私はそのコマーシャルを知っています。少なくとも、必要なものはすべて見つけました)。コア GWT よりもラッパー ライブラリを使用するのが賢明だと思いますか?

前もって感謝します。

4

3 に答える 3

3

上記の要件は GWT で対応できますか?

はい（@Andrey Kapelchikの回答を参照）。

GWT を使用するという決定は賢明だと思いますか、それとも他に推奨事項はありますか?

あなたの背景とあなたが言及した点を考えると、それは非常に良い決断だと思います. 私は JavaScript や jQuery などでアプリを作成しましたが、コードが 1000 行を超える場合は、JavaScript アプリを「手動で」再度作成したくありません。私にとって決定的なポイント：

  • GWT を使用すると、サーバー側とクライアント側の両方でコードの一部を再利用できます。たとえば、クライアント側で検証してすぐにフィードバックを提供し、同じコードを使用してセキュリティのためにサーバーで再度検証することができます。
  • 私は、大規模な GWT プロジェクトの方がはるかに簡単だと思います。大規模な JavaScript コードでも明確な方法で配置することは確かに可能ですが、常に扱いにくくなる傾向があります。
  • 私は常に IDE 機能 (リファクタリング、フィールドへの書き込みアクセスの検索など) を集中的に使用しており、JavaScript の IDE サポートは私にはあまりにも限られています。

あちこちで JavaScript の知識が少し必要になります。あなたのチームは間違いなく CSS を学ぶべきです。選択したクライアント側のフレームワークに関係なく、徹底的に学ぶことをお勧めします。

私たちは、sencha gxt が最高のウィジェット ライブラリを持っていることを発見しました (私はそのコマーシャルを知っています。少なくとも、私たちが必要とするすべてのウィジェットを見つけました)。コア GWT よりもラッパー ライブラリを使用するのが賢明だと思いますか?

私が取り組んでいるいくつかのプロジェクトでは、GXT を使用しています。これは、その決定が数年前に行われたためです。私の意見は次のとおりです。デスクトップ アプリに非常によく似たものを構築する必要がある場合は、GXT が最適かもしれません。

純粋な GWT で最高のパフォーマンスが得られます。CSS を知っていれば、はるかに柔軟です。GXT には優れた機能がいくつかありますが、その制限、重大なパフォーマンスの問題 (および場合によってはバグ) を回避するには、かなりの時間がかかる可能性があります。特別な GXT ウィジェットが本当に必要な場合でも、純粋な GWT アプリを作成してから、その 1 つの GXT/SmartGWT ウィジェットだけを追加できます。

于 2012-08-08T09:21:05.427 に答える
2

GWTは、説明したプロジェクトの要件と目的に最適だと思います。GWTには、ネイティブJavaScriptを使用するためのJavaScriptNativeInterfaceがあります。JSNIを使用すると、GWTを既存のJavaScriptまたは外部JSライブラリと統合できます。JavaScriptをアプリケーションのJavaソースコードに直接統合できるようにすることで、これらの問題を解決します。

于 2012-08-08T07:25:49.960 に答える
1

私のチームは、多くの不正スタートの後、この問題に本当に苦労しました。JavaScriptは実際には避けられず、習得するのは私が恐れていたほど悪くはないと判断しました。GWTで立ち上がるのにかかる時間は、クライアント側のJSMVCフレームワークで立ち上がるのにかかる時間とほぼ同じです。

GWTを検討しましたが、次の理由で長期的に維持するのが難しいため、GWTを削除しました。

  • GWTの開発者がそれを維持することに興味を失った場合、GWTのようなものを維持するには本当に洗練されたスキルセットが必要になります。
  • 私たちが望む可能性のあるウィジェットは、他のGWTで利用できる可能性があり、GWTへの移植は私たちが望むよりも多くの作業になる可能性があります。
  • 最新のJavaScriptMVCフレームワークは、複雑な1ページのアプリの開発を容易にする多くの非常に優れた機能を備えて非常に成熟しています。
  • ブラウザが改善され、JSフレームワークが改善され、より高度なフロントエンド開発者にとってより簡単になります...など。

また、道場のカスタマイズはチームにとって難しすぎると感じたため、道場を評価してダンプしました。これが私たちが最終的に得たものです。

  1. CSS/ウィジェットフレームワーク用のTwitterBootstarp
  2. さまざまなjqueryプラグインがオンラインのさまざまな場所から集まってきました
  3. JQuery、バックボーン、クライアント側MVCフレームワークのハンドルバー。

今日プロジェクトを再開する場合は、GoogleのAngularJSを使用します。これは、クライアント側のWebアプリを構築するためのすばらしいアプローチです。特に、JavaScriptでの依存性注入の巧妙な使用と、双方向の入札およびその他の多くの理由によります。私はThroneofJSカンファレンスに参加していて、Google AngularJSの連中は、17,000行のGWTアプリを2500行のangularJSアプリに移植したと言っていました。

于 2012-08-08T07:25:55.583 に答える