6

私は javascript フレームワーク、特に jQuery の大ファンです。私はいつも「plurk.com」のようなサイトをデザインしたいと思っていましたが、非常に膨大な数の javascript が必要であることを知っています。本当に試してみたいので、javascript やそのフレームワークよりも複雑なものを開発するのが私たちの仕事をより簡単にするかどうかを尋ねたいと思います.どちらが好きですか?

4

6 に答える 6

22

この質問に対する回答のいくつかはまったく知らされていないと思います。それらに回答する人々は、大規模なプロジェクトでGWTを使用したことがないのではないかと思います。はい、GWTは大規模なAJAX Webサイトを作成するための優れた方法であり、バックエンドも含む大規模で複雑なサイトの場合、JQueryのようなものをパークの上下にキックします。私がいつも見ているのは、JavaScript自体が小さなクライアントサイドのことをするのに最適だということです。より複雑なこと（動的フィールド、ポップアップ、アニメーションなど）を実行する必要がある場合は、JQueryやPrototypeなどを導入します。さらに一歩進めたい場合は、GWTを使用します。

Javaで記述しているため、バックエンド開発者がフロントエンド開発を行うために設計されていると思われます。そうではありません。Javaは単に彼らが選んだ言語です。主な理由は、Javaが広く使用され、静的に型付けされており、優れたエディターがたくさんあるからです。

リークのある抽象化理論も購入しません。HTML要素を完全に抽象化しようとはしません。ネイティブJavaScriptとDOMの両方を使用することを選択した場合、それらに直接アクセスできるからです。

つまり、GWTで非常に複雑なサイト（そのうちの1つはGWTブログで紹介されています）を構築し、JQueryなどの他のライブラリも使用しています。GWTに頭を悩ませると、複雑なタスクのために他のフレームワークが死んでしまうことを100％の自信を持って伝えることができます。また、物事を改善するのに役立ついくつかの優れた機能が組み込まれており、他のフレームワークではサポートされていないいくつかのことも実行します（画像で実行できる魔法など）。詳細については、次のブログ投稿を参照してください。

http://googlewebtoolkit.blogspot.com/2007/10/epo-builder-built-with-gwt.html

于 2009-01-06T22:01:12.690 に答える
7

「生成されたJavascript」のように私を怖がらせるものはほとんどありません。 これらのケースでは、漏れやすい抽象化の法則が二重に当てはまります。

効果的なクロスブラウザー JavaScript を作成することは、継続的な改良のトリッキーなプロセスです。生成された不明瞭な Javascript がどこでうまくいかないのかを解読しようとすることは、大きな頭痛の種です。純粋な JS ライブラリのバグを修正するだけでは不十分です。

私にとって、GWT は、バックエンド開発者がフロントエンドのブラウザー内コードを記述できるようにすることを目的としたトリックです。残念ながら、最新の Web アプリの現実は、Javascript と DOM を知っていればよいことを意味します。何かが壊れそうで、その理由を知る必要があります。

jqueryやprototypeなどの優れたjavascriptライブラリを選択して、それをよく学習した方がよいと思います。これらのライブラリは、配列操作や AJAX リクエストなど、抽象化する必要があり、エッジ ケースで壊れる可能性が低いものを抽象化します。

于 2009-01-06T16:04:43.877 に答える
4

はい、そうです。Javascript ではなく Java を使用するためです。

優れた IDE、静的コード分析、検索、およびリファクタリング - これらすべてにより、大規模なプロジェクトでの作業が大幅に楽になります。

于 2009-01-06T16:02:28.330 に答える
3

いいえ、そうではありません。

複雑さがなくなるわけではなく、Java の観点から対処できるようになるだけです。これにより、Java から利用可能なすべてのツールが提供されるため、それだけでも価値があるかもしれません。

ただし、JavaScript IDE はますます良くなっています。通常、jQuery や Prototype などのフレームワークを使用している場合は、GWT のような重い抽象化レイヤーを扱うよりも簡単であることに気付くでしょう。

私の個人的な好みは、純粋な JavaScript アプローチを採用することですが、それは、より金属に近い作業ができるのが好きであり、JavaScript 猫を飼いならすのに十分な規律を持っているからです。

于 2009-01-06T15:59:44.793 に答える
2

私は、GWT を使用してかなり効果的なプロジェクトに取り組んでいます。私たちは皆、主に内部ツールに取り組んでいる Java 開発者であるため、これは良い選択です。大規模なエンド ユーザー サイトでの有用性については、私には語り尽くせません。

私が特に評価している利点の 1 つは、シームレスなオブジェクトのシリアル化と逆シリアル化です。XML-RPC の詳細が抽象化されるだけでなく、同じ Java コードがサーバー用のバイト コードとブラウザー用の JavaScript にコンパイルされるため、サーバーとクライアントが別のクラス ローダーで実行されているかのようにコーディングできます。同じJVM。たとえば、サーバー上で Java オブジェクトを構築し、それを RPC サービス呼び出しからの戻り値としてブラウザに送信すると、ブラウザ コードは同じ Java クラスを使用して、返されたオブジェクトを操作できます。同様に、RPC 呼び出しのパラメーターは Java オブジェクトとして構築でき、サーバーは相手側で同一の Java オブジェクトを受け取ります。(デ)シリアライゼーションの詳細をいじる必要はありません。

于 2009-01-06T17:32:00.567 に答える
2

GWT では、実際に JavaScript を書いているわけではありません。全体的な価値提案は、JavaScript にコンパイルされる Java を記述できることです。

于 2009-01-06T15:43:13.500 に答える