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