我想创建一个数据库支持的交互式AJAX webapp，它具有自定义（特定种类的事件，编辑）日历系统。这将涉及到很多JavaScript和AJAX，我想到了用于接口的Google Web Toolkit和用于服务器端的Ruby on Rails。我应该为我的新webapp使用Google Web Toolkit吗？
Google Web Toolkit的可靠性和良好性？如果我选择Google Web Toolkit，可能存在哪些隐患？可以轻松地将它与服务器端的Ruby on Rails结合起来吗？或者我应该尝试直接使用像jQuery这样的JavaScript库？我有没有web开发经验，除了一些HTML，但我是一个有经验的程序员（c + +，java，c＃），我想只使用这个项目的免费工具。
您可以使用GWT在Java中编写所有代码，并且可以将现有的第三方JavaScript库与它集成。这很好。虽然我从来没有使用过RoR，所以对此无话可说。
如果你有Java的经验，但不是Javascript/CSS，那么GWT将成为一个救生员（当然，除非你想学习它们）。 CSS有那么多小小的细节。花费半天的时间修复只发生在IE6中的2像素错位并不罕见。
我不确定在后端使用ROR会是多么容易......我相信这是可能的，因为GWT ajax通信只是servlet。但是它们提供了一些非常好的功能来传递Java对象，如果您的服务器不使用Java，那么您将无法使用它们。
你也可以考虑Grails（“Groovy on Rails”），它给你带来了Rails框架的好处以及Java VM的使用。
如果你知道JAVA，并且有一个地方可以托管它（比如一个tomcat或者glassfish容器），那么我会推荐这比使用Ruby做后端更多。主要原因是你可以共享你的所有对象，并使用内置的RPC机制。我已经完成了很多项目，这是一个巨大的时间段，更不用说代码不太容易出错，因为您不会将Java对象转换为任何东西，然后再返回。
我已经将我的GWT与Rails链接起来，在Rails中使用to_json函数，然后阅读GWT中的JSON。这一切都得到了支持，但它比在JAVA中做后台更麻烦。
当然，如果你有便宜的主机，那么Java容器几乎是不可能的，在这种情况下，我会认为Rails会成为下一个最好的东西。
GWT是一个非常优秀的社区。然而，如果你想调整事物的外观，你确实需要知道CSS - 如果你愿意，CSS可以做很多布局，就像普通的web一样。像GWT-ext或ExtGWT这样的图书馆可以提供一些帮助，因为它们具有令人惊叹的“开箱即用”外观，但价格较高（适用于您应用的尺寸）。
如果您希望将GWT与非Java后端（如ROR，PHP等）集成在一起，那么您应该记住GWT 1.5现在支持JavaScript Overlay类型。利用此功能，您可以编写可以映射到本机JavaScript对象顶部的类，以轻松为这些对象的属性和其他扩展功能提供访问器方法。
请参阅此链接了解详情： JavaScript Overlay Types
所以，你可以从你的后端返回JSON编码的数据通过AJAX调用，它解析为JavaScript对象，然后通过自己的GWT的Java代码使用覆盖访问数据你创建的类。或者，当您渲染页面时，您可以将静态配置数据呈现为JavaScript对象，并通过此机制读取它，而不必执行AJAX调用来获取数据。
我最近写了一些关于the disadvantages of GWT的一些。主要缺点是：对应用程序的某些部分进行更改的部署周期较长，学习曲线相当陡峭。作为经验丰富的Java程序员，第二个应该不是什么问题，如果使用单独的后端，第一个也会减轻（因为当您更改应用程序的“服务器”部分时，主要需要完成重新部署）。
GWT是一个很好的框架，有很大的潜力。请记住，它仍然是相当新的，但。有一些未解决的错误可能会让你感到困扰，并且他们通常需要丑陋的解决方法才能过去。这个社区很棒，但你可能迟早会遇到一些Google无法回答的问题。
但是，嘿，我说去吧。 GWT的潜力非常棒，我敢打赌，未来将是光明的。
你应该使用GWT来创建一个新项目（在旧项目中使用它也很容易）。
我的经验是学习和使用非常快。编译后的JavaScript代码比你手动编写的任何东西都要好得多，而且它的工作速度也很快。
另一个好处是可以调试你的代码（这是地狱单独的JavaScript）
这个博客有许多经验丰富的GWT的用户输入，有一些很棒的讨论点的能力。我个人对各种UI框架有丰富的经验。我会补充我的两分钱。让我们看一下根本优势和GWT
基本优势
GWT需要在网络层编程JAVA的缺点。所以，Java的明显优势开始发挥作用。它将提供面向对象的编程。它还会提供很好的调试和编译时间检查。由于它生成HTML和Javascript，因此它也能够隐藏其生成器中的一些复杂性。
主要缺点
缺点来自相同的语句开始。 GWT将Web层编程转换为JAVA。如果你知道JAVA，那么你可能永远不会选择另一种语言来编写你的业务逻辑。这是自给自足的，很棒。但是当涉及到为JAVA应用程序编写配置时。我们使用属性文件，数据库，XML等。我们从不将配置存储在JAVA类文件中。想一想，那是为什么？
这是因为配置是一个静态数据。它通常需要层次结构。它应该是可读的。它从不需要编译。它不需要JAVA编程语言的知识。总之，这是一个不同的球赛。现在的问题是，它与我们的讨论有何关系？
现在，让我们考虑一个网页。你认为当我们写网页时，我们写了一个业务逻辑？绝对不。网页只是一个配置。它是分层容器和字段的配置。我们需要为将从网页捕获并显示的数据编写业务逻辑，而不是创建网页本身。
上一段做了非常强烈的陈述。这将解释为什么基于HTML和XML的网页仍然是最受欢迎的网页。 XML是编写配置的最佳业务。框架必须允许将网页与业务逻辑（MVC框架的目标）清晰分离。通过这样做，网页设计师将能够运用他的可视化和艺术技能，通过配置XML来创建精美的网页，而不用担心编程语言的错综复杂。开发人员将能够在商业JAVA中使用他们最好的商业逻辑。
最后，让我们直接讨论其影响。 GWT打破了这个原则，所以它必然会失败。开发GWT应用程序的成本会非常高，因为您需要multiskill程序员来编写网页。所需的外观和感觉将很难实现。由于不必要的编译，修改网页的转身时间将非常高。最后，由于您正在使用JAVA编写网页，因此使用业务逻辑很容易破坏它。不知不觉中，你会引入必须避免的复杂性。
我们的团队最近问了同样的问题，并且我们选择使用GWT，特别是因为设计者插件使得GWT更容易被团队中的非Java专家使用。无论谁做出这个选择，只要注意你不要使用GWT Designer插件！它没有被更新（至少在一年内，显然）创建一个与IE8兼容的GWT应用程序。
我们的团队几乎完成了我们的应用程序布局，这些布局在Chrome，FF和Safari中完美运行。然后他们在IE中爆发。 IE 7将加载部分页面（但不包括复合包含），IE8甚至无法加载应用程序。它只是挂起来。
设计器插件具有按钮，允许用户添加与IE不兼容的CellTable小部件（CellTable，DeckPanel，水平面板，垂直面板等）。当布局必须在没有设计人员协助的情况下用java重新完成时，这些会造成很大的痛苦。
有经验的GWT用户喜欢它，但设计者插件会杀了你。
这不是以破碎的英语来哄骗你的技术的地方 – Yarin 2010-06-20 12:27:24