私の会社は、まったく新しい Web フロントエンド アプリケーションの開発を計画しています。
背景:
Silverlight または従来のテクノロジ (Javascript、jquery、CSS など) の代わりに GWT を使用することを推奨する人がいます。
これが正しい方法かどうかわかりませんか？GWT ニュースの多くは 2007/2008 のものです。このテクノロジーは古く、おそらく死んでいると思います。
選択肢があるとしたら、GWT を選びますか?
残念ながら、このコンテキストでは、2つのステートメントが相互に排他的です。
私は昨年かそこらでGWTを手にしたJavaプログラマーです。コンパイルされた言語と成熟した開発ツールを使用してブラウザに直接書き込むことができることは非常に効果的です。これまでになく高速にWeb開発を進めることができます（ASP、JSP、ExtJSを使用...）。
しかし、他のコメント提供者が言っているように、Javaの経験がない場合は、両方のテクノロジー（JavaとGWT）を短時間で習得するのは非常に難しいでしょう。妥当な時間内に市場に投入できた場合、コードベースの状態が非常に悪いと想像することしかできませんでした（学習しながら学習するため）。これは、組織の輝かしい新機能の基盤としては非常に貧弱です。ベンチャー。
ここでも、リストした他の関連スキルには「たくさんの」スキルがありません。
もっと効果的な解決策があるのではないかと思います。賢明な古いヤギのプロジェクトマネージャーが言ったように：
プロジェクトを実現するには、時間、コスト、品質の3つの変数があります。任意の2つを選択してください
あなたの状況では、組織が短期間で高品質の製品を望んでいる場合、それを補う必要があるのはコスト要因です-組織は、健全なソフトウェアアーキテクチャを提供し、今後数か月間チームを指導するために、暫定的なGWTの専門知識を購入する必要があります。その後、「巨人の肩の上に立つ」ことで高品質のコードベースを継承し、統治する準備が整います。
他の人が言っているように、GWT は間違いなく死にゆくプロジェクトではありません。実際にはまったく逆で、現在 Google 内から 20 人以上の定期的な寄稿者がいます (2008 年には半ダースだったのに対し)。Wave (Google サービスとしては廃止されましたが、Apache Foundation プロジェクトとして存続しています)、Orkut、AdWords、Google モデレーター、および新しい (まだベータ版の) Google グループは GWT で作成されています。また、Google Buzz の一部や Google の他のいくつかのプロジェクトも、これを使用して構築されています。
あなたの選択について：
したがって、あなたのニーズ/欲求とスキルに応じて、GWT または「いくつかの JS ツールキット」を選択します。いずれにせよ、ルック アンド フィールを完全に制御できます (肥大化したプレイヤーの 1 つを選択しない限り: ExtJS/ExtGWT、SmartGWT など。おそらくこれらを使用すると、市場投入までの時間が短縮されますが、パフォーマンス、他のツールキットとの統合、およびルック アンド フィールに関しては、後で支払います)。
あなたのスキルについてあなたが言っていることに照らして、GWT を強くお勧めします (Java の経験がないにもかかわらず)。JavaScript の経験の欠如は、Java の経験の欠如よりもはるかに悪いためです (「大規模なアプリケーション」について話しているので、物事を正しく構築し始めること、および/またはリファクタリングを支援するツールを用意することが非常に重要です。 Javaで）。
@ianmayo は、私が上記を書いている間に返信しました。
上記の一見全会一致の回答で読者を誤解させないために、尊重されたスタックオーバーフローで客観的な視点を保ち、次のレビューでGWTを使用した正確な経験を表明しました。GWT が消滅するかどうかは、GWT を採用する新しいアプリの数に依存します。
https://softwareengineering.stackexchange.com/questions/38441/when-not-to-use-google-web-toolkitからの抜粋
> 私はこの質問に答えるのが得意でもあり、不得意でもあります。GWT を使用する前に HTML/CSS/JavaScript の経験が豊富だったという点で、以前に実際に使用したことがあるという点で良い点と悪い点です。これは、DHTML を本当に知らない他の Java 開発者がそうでなかったかもしれない方法で GWT を使用することに腹を立てました。
GWT はその名の通り、JavaScript を抽象化し、HTML をある程度 Java に抽象化します。多くの開発者にとって、これはすばらしいことのように思えます。ただし、Jeff Atwood が述べているように、すべての抽象化は失敗した抽象化であることがわかっています (GWT を検討している場合は、一読の価値があります)。GWT では、これにより具体的に次の問題が発生
します。 GWT で HTML を使用するのは最悪です。
私が言ったように、ある程度、HTML を抽象化することさえあります。Java 開発者にとっては良さそうです。しかし、そうではありません。HTML はドキュメントのマークアップ形式です。ドキュメントを定義するために Java オブジェクトを作成する場合は、ドキュメント マークアップ要素を使用しません。それは非常に冗長です。また、十分に制御されていません。HTML では基本的に 1 つの書き方があり
<p>Hello how are <b>you</b>?</p>
ます。GWT では、P ノードに接続された 3 つの子ノード (テキスト、B、テキスト) があります。最初に P を作成するか、最初に子ノードを作成することができます。子ノードの 1 つは、関数の戻り結果である可能性があります。多くの開発者と共に数か月の開発を行った後、GWT コードをトレースして HTML ドキュメントがどのように見えるかを解読しようとするのは、頭痛の種となるプロセスです。
最終的に、チームは、おそらくすべての HTML に HTMLPanel を使用することが正しい方法であると判断しました。ここで、データを簡単にバインドするために、要素を Java コードですぐに使用できるという GWT の利点の多くを失ってしまいました。
GWT で CSS を使用するのは最悪です。
HTML の抽象化に付随するということは、CSS の使用方法も異なるということです。最後に GWT を使用したとき (約 9 か月前) から改善された可能性がありますが、当時は CSS サポートがめちゃくちゃでした。GWT で HTML を作成する方法のために、インジェクトされたことを知らなかったノードのレベルが存在することがよくあります (CSS 開発者なら誰でも、これがレンダリングにどのように劇的に影響するかを知っています)。CSS を埋め込んだりリンクしたりする方法が多すぎて、名前空間が混乱する結果になりました。それに加えて、スプライトのサポートもありました。これもまた良さそうに聞こえますが、実際には CSS を変更し、後で明示的に上書きしなければならないプロパティの書き込みに問題がありました。 CSS をコーディングし、GWT が台無しにしないように再設計する必要がありました。
問題の結合、利点の交差
どの言語にも、独自の問題と利点のセットがあります。使用するかどうかは、それらに基づいた加重式です。抽象化すると、得られるものはすべての問題の結合であり、利点の交差です。JavaScript には問題があり、サーバーサイドのエンジニアの間では一般的に嘲笑されていますが、迅速な Web 開発に役立つかなりの数の機能も備えています。クロージャー、シンタックス ショート ハンド、アドホック オブジェクト、Jquery によって行われるすべてのもの (CSS セレクターによる DOM クエリなど) を考えてみてください。GWT で使用することは忘れてください。
関心事の分離
プロジェクトの規模が大きくなるにつれて、関心を適切に分離することが重要であることは誰もが知っています。最も重要なことの 1 つは、表示と処理の分離です。GWT はこれを非常に困難にしました。おそらく不可能ではありませんが、私が所属していたチームは決して良い解決策を思いつきませんでした。
デスクトップ != ウェブ
@Berin Loritsch がコメントに投稿したように、GWT のモデルまたは考え方は、プログラムが処理エンジンと密接に結合された生きたディスプレイを持つ生きたアプリケーションのために構築されています。多くの人が Web に欠けていると感じていることなので、これは良さそうです。しかし、2 つの問題があります: A) Web は HTTP で構築されており、これは本質的に異なります。上で述べたように、HTTP で構築されたテクノロジ (HTML、CSS、さらにはリソースの読み込みとキャッシュ (画像など)) は、そのプラットフォーム用に構築されています。B) Web で作業してきた Java 開発者は、このデスクトップ アプリケーションの考え方に簡単に切り替えることはできません。この世界の建築は、まったく別の分野です。Flex 開発者は、おそらく Java Web 開発者よりも GWT に適しているでしょう。
結論は... GWT は、Java だけを使用して非常に簡単に、素早くダーティな AJAX アプリケーションを作成することができます。クイック アンド ダーティがあなたの望むものに聞こえない場合は、使用しないでください。私が働いていた会社は、最終製品に非常に気を配る会社であり、ユーザーにとって視覚的およびインタラクティブな洗練された感覚です。私たちフロントエンド開発者にとって、これは、GWT をボクシング グローブをはめてピアノを弾こうとするような方法で、HTML、CSS、および JavaScript を制御する必要があることを意味しました。
GWTは間違いなく古くなく、死にかけているわけでもありません。Google独自のアプリケーションの多くは、GWTを使用して開発されています。GBSTのケーススタディをダウンロードして、グローバルな金融会社がGWTを使用して生産性を向上させ、リッチなユーザーエクスペリエンスを作成する方法を学ぶことができます。GWTを使用すると、javascript、htmlなどが自動的に使用されることを知っておく必要があります。gwtアプリケーションはjavaで作成しますが、コンパイルすると、gwtはhtmlファイル、javascriptコード、cssなどを含むフォルダーを作成します。
私は間違いなくそれをお勧めします！
まず第一に、GWT は死にゆく技術ではなく、その使用量は増加しており、その最新バージョンは 2.2 です。バージョン 1.6 から 2 年間 GWT を使用しています。それら以来のその改善は非常に驚くべきものです。
GWT はクライアント側のテクノロジであるため、アプリケーションのスケーラビリティ機能にプラスの効果しかありません。jsf、struts、wicket などのサーバー側の Web テクノロジはサーバー リソースの消費者ですが、gwt はユーザー インターフェイスをレンダリングするためにサーバー リソースを必要としません。
しかし、あなたのチームには問題があります。あなたのチームは Java の経験がないため、Java と gwt の 2 つの新しいテクノロジーを自分で適応させるのは非常に困難です。学習する時間があれば、GWT を強くお勧めします。
GWT に習熟するには約 1 年かかります。MicrosoftOffice や PhotoShop のような洗練されたアプリケーションを開発する場合、GWT を使用すると効果があります。小規模で比較的単純なアプリに GWT を使用しても意味がありません。GWT は実に暇つぶしのフレームワークであり、それを使用するには非常に強い理由が必要です。Web アプリの 99% は GWT を必要としないと思います。
GWT は死にゆくフレームワークではなく、時間をつぶすフレームワークです。セキュリティ上の問題があります。GWTアプリケーションへのCSRF(クロスサイトリクエストフォージェリ)リクエストを簡単に行うことができます。また、Java と Javascript はまったく異なる言語であるため、簡単に翻訳することはできません。生産性のために、GWT は避けてください。