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