Google Web Toolkitを使用しない場合 [閉まっている]

社内の主要なWebアプリ開発プロジェクトでGWTを使用することを検討しています。つまり、私の目での主な利点は、Javaスタックへのクロスコンパイルであり、（少なくとも理論的には）技術スタックのサイズを1つ削減するのに役立ちます。

ただし、（ほとんどの開発者と同様に）以前に焼かれたことがありますが、特定の問題ドメイン内での使用を妨げる、または制限するGWTの問題で実際に使用したプログラマーから聞いてみたいと思います。

GWTの使用に反対する論拠は何ですか？

私はこの質問に答えるのは良いことも悪いこともあります-実際にそれを実際に使用したことがあるという点で良いのですが、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では、3つの子ノード（テキストB、テキスト）がPノードに接続されています。最初にPを作成するか、最初に子ノードを作成できます。子ノードの1つは、関数の戻り結果である場合があります。多くの開発者による数ヶ月の開発の後、GWTコードをトレースしてHTMLドキュメントの外観を解読しようとすることは、頭痛の種となるプロセスです。

最終的に、チームはすべてのHTMLにHTMLPanelを使用することが正しい方法であると判断しました。これで、Javaコードで要素を簡単に利用してデータに簡単にバインドできるというGWTの利点の多くを失いました。

GWTでCSSを使用するのは面倒です。

HTML抽象化に添付することにより、これはCSSの使用方法も異なることを意味します。私が最後にGWTを使用してから（約9か月前）改善された可能性がありますが、当時はCSSサポートが混乱していました。GWTがHTMLを作成する方法のために、多くの場合、インジェクトされたことを知らなかったノードのレベルがあります（CSS開発者は、これがレンダリングに劇的に影響する方法を知っています）。CSSを埋め込んだりリンクしたりする方法が多すぎて、結果として名前空間が混乱してしまいました。その上、スプライトのサポートがありましたが、これもいい感じですが、実際にCSSを変更し、プロパティの書き込みに問題があり、後で明示的に上書きする必要がありました。 CSSをコーディングし、GWTがそれを台無しにしない方法で再設計する必要がありました。

問題の連合、利益の交差点

どの言語にも、独自の問題と利点があります。使用するかどうかは、それらに基づいた加重式です。抽象化された場合、得られるのはすべての問題の結合であり、利益の交差点です。JavaScriptには問題があり、一般的にサーバーサイドエンジニアの間でridされていますが、迅速なWeb開発に役立つかなりの数の機能も備えています。クロージャ、シンタックスショートハンド、アドホックオブジェクト、Jqueryが行うすべてのこと（CSSセレクタによるDOMクエリなど）を考えてください。GWTで使用することを忘れてください！

関心事の分離

プロジェクトの規模が大きくなるにつれて、懸念を適切に分離することが重要であることは誰もが知っています。最も重要なものの1つは、表示と処理の分離です。GWTはこれを本当に難しくしました。おそらく不可能ではないかもしれませんが、私がいたチームは良い解決策を思いつきませんでした。

デスクトップ！= Web

@Berin Loritschがコメントに投稿したように、GWTのモデルまたは考え方は、プログラムが処理エンジンと密接に結合された生きているディスプレイを備えた生きているアプリケーション向けに構築されています。これは、多くの人がウェブに欠けていると感じるものだからです。しかし、2つの問題があります。A） WebはHTTP上に構築されており、これは本質的に異なります。上で述べたように、HTTP、HTML、CSS、さらにはリソースのロードとキャッシング（画像など）に基づいて構築されたテクノロジーは、そのプラットフォーム用に構築されています。B） Webで作業してきたJava開発者は、このデスクトップアプリケーションの考え方に簡単に切り替えられません。この世界の建築は、まったく異なる分野です。Flex開発者は、おそらくJava Web開発者よりもGWTにより適しています。

結論として...

GWTは、Javaのみを使用して、簡単に汚れたAJAXアプリケーションを簡単に作成できます。クイックアンドダーティが望みどおりに聞こえない場合は、使用しないでください。私が働いていた会社は、最終製品を大事に考えていた会社で、ユーザーにとって視覚的かつインタラクティブな洗練された感覚です。フロントエンドの開発者にとって、これは、ボクシンググローブを装着してピアノを演奏するようなGWTの使用を可能にする方法でHTML、CSS、およびJavaScriptを制御する必要があることを意味しました。

GWTは、使用頻度の高い大きなeGovernment Webアプリケーション（バックエンドのSOA）に使用します。古いUIはDHTMLでしたが、ブラウザーの互換性、パフォーマンスの最適化、開発プロセスに問題があったため、代替手段を探しました。

要件は次のとおりです。

• サーバーの負荷を最小限に抑えるクライアント側UIレイヤー
• ブラウザの互換性
• ウェブベースのRIA
• 簡単なパフォーマンス最適化
• クライアントプラグインのインストールは不要です。プレーンなWindowsインストールで動作するはずです。

GWTを選択しましたが、後悔することはありません。新しいチームにはDHMTLの経験がないか、少ないため、GWTのJava開発プロセスは非常に役立ちました。あなたが箱から得るものは：

• ブラウザの互換性
• Javaベースの開発プロセスとコードの再利用
• リクエストの最小化が簡単（イメージバンドルなど）
• 簡単なアグレッシブキャッシング（新しいアプリはクライアント側で完全にキャッシュされます）
• すべてのリソースの簡単な圧縮（古いバグのあるIEのjsでも）
• そして、もっと多くのことをここで言及します

このアプリケーションは、起動時にサーバーに1つのリクエストのみを発行します。マイナス面は、GWT（およびAndroid）のデザインがすぐに貧弱であることですが、とにかく独自のルックアンドフィールを適用する場合は、CSSを適応させる必要があります。または、GWTのさまざまなコンポーネントライブラリを使用して、適切なスタイルとテーマを簡単に適用できます。

私にとって、HTML DOMが手作りのものほど良くないという点はありません。これは決して問題ではありませんでした。C ++で開発するとき、生成されたアセンブラコードを確認しません。GWTで開発するとき、JSコードを見る理由はなく、DOMを見てリファクタリングを行う理由は一度だけでした。

私にとって、GWTはRIA開発に関して唯一の選択肢であり、GWTに明るい未来があることを願っています。ミッションステートメントをご覧ください：

[1] http://code.google.com/intl/de-DE/webtoolkit/makinggwtbetter.html#introduction

ただし、Googleが内部プロジェクトの多くでGWTを使用していないこと、そして現時点ではGWTの将来についていくつかの噂があることを言及してはなりません。

[2] http://googlewebtoolkit.blogspot.com/2011/11/gwt-and-dart.html
[3] https://plus.google.com/105933370793992913359/posts/bLfSagtziBC