私はマイクロソフトの世界から来ました（そして私は安心して来ます）。Webアプリのプロトタイプを迅速に作成したいのですが、うまくいったら、ライブで公開します。ASP.Netは使いたくありません。
ただし、どのWebアプリケーションツールキットを使用するかはわかりません。GWT、DOJO ...その他の推奨事項を使用する必要がありますか？私はあらゆるサーバーサイド言語を受け入れていますが、RoR、Php、さらにはJava（正確にはJ2EE）を検討しています。私はJavascript/CSSの専門家ではないので、これらの面で比較的簡単にできるツールキットが望ましいでしょう。
また、私は自宅でMacユーザーです。どのIDEが、推奨するフレームワークに対応していますか？
おすすめの人はいますか？
あなたがJavaをやる気があるなら、GWTがその方法です。これにより、クライアントサーバー全体で比較的均一なコードベースを使用でき、両方で1つの言語のみを使用できます。
非常に風変わりなAJAXyのことを行うにはいくつかの制限があります（GWTは困難ですが、不可能ではありません）が、とにかくそれがあなたのユースケースのようには思えません。
GWTを使用すると、アプリがより複雑になるにつれて、その機能をより多く使用してスケールアップできます。また、プロトタイプが使い捨てのコードになることはありません。
フロント エンドとバック エンドを Java で記述し、複雑な ajax タイプの処理を行いたい場合は、GWT が最適です。
これについて考える最も簡単な方法は、GWT アプリを構築することは、サーバーにフックする Java スイング アプリケーションを構築するようなものだということです。サーバーを使用するスイングアプリのように、ファットまたはシンにすることができます。完了すると、すべてが HTML と JavaScript にコンパイルされ、非常に優れた最新のブラウザー (ie6+ ff、opera、safari) がサポートされます。
すべての JavaScript と HTML が抽象化されていますが、見栄えを良くしたい場合は、CSS を理解する必要があります。
それが MVC を台無しにするとか、クライアントとサーバーの混乱だと言う人は、GWT を理解していないと思います。GWT はクライアント側のフレームワークです。また、CLIENT でのみ使用されます。GWT は Java (およびその他の) バックエンドにフックする RPC メカニズムを提供しますが、それは単なる通信プロトコルであり、サーバー コードが魔法のようにクライアント コードになるという意味ではありません。確かに、本当にやりたいのであれば、大量のビジネス ルールを UI に書き込むことができますが、これは任意のフレームワークで行うことができるため、GWT がその点で何らかの形で異なると言うのはばかげています。
GWT は良い選択ですが、GWT に基づくより強力な JavaScript フレームワーク (SmartGWT など) を選択すると、コンパイルされたものが重くなりすぎます。
コンパクトなプロジェクトが必要な場合は、ダイレクト JavaScript を選択してください。
私はGWTのファンですが、Javaには非常に精通しています。直感的で、驚くほど簡単にすぐに良い結果を得ることができました。GWTを使用する場合は、無料で非常に強力なEclipseIDEを使用することをお勧めします。
GWTの欠点の1つは、ブラウザでJavascriptをサポートする必要があることです。これにより、「適切な劣化」が発生しません。
私は jQuery のファンです。アクション、トラバーサル、およびコマンドの連鎖可能性は非常に強力です。私の親友は Mootools に夢中で、Java ショップ FWIW で働いています。彼は、Mootools の優れた機能は、フレームワークに含めたい機能を指定できることであり、フレームワークの重量を最小限に抑えるためにページに含めることができるファイルの 1 行でライブラリ全体を生成することだと述べました (かなりクールな機能）。本当に、それはあなたが最も快適なものに依存します. jQuery には優れたチュートリアルがあり、超高速で、他の JavaScript フレームワークと一緒に使用できます。
GWT とは関係ありませんが、GWT とうまく連携できる他のバックエンドを検討しましたか?
Grails は、GWT と非常にうまく連携するバックエンドの 1 つです。
個人的には、クライアント側のフレームワークを埋め込んだり隠したりしようとするサーバー側のフレームワークは避けたいと思います。GWT は、何かを迅速に処理するのに最適であり、特定の種類のアプリケーションにはおそらく適していると確信していますが、より複雑なアプリケーションの場合、「エッジで」多くの問題に遭遇するでしょう。クライアント フレームワークをサーバー側フレームワークから切り離すことで、これらの問題を回避できます。