我应该将Google Web Toolkit用于我的新网络应用吗？

Question

我想创建一个数据库支持的交互式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＃），我想只使用这个项目的免费工具。

Answer 1

实际上，只要您正确使用REST，RoR实际上就是GWT能够很好地工作的事情之一。它位于Google Web Toolkit应用程序手册中，您可以使用这种想法here查看本书中的演示。这并不是说你不会有任何问题，但我认为支持肯定是出于此目的。

有一个简单的项目可以让你轻松找到RoR / GWT here（麻省理工学院执照）。我还没有机会试一试，但看起来已经考虑了很多想法。一个问题是看起来它还没有完全通过2.1 Rails测试，只有2.0，所以你可能会遇到一些（可能是次要的和可修复的）错误。

Answer 2

如果您希望将GWT与非Java后端（如ROR，PHP等）集成，您应该记住GWT 1.5现在支持JavaScript Overlay类型。此功能允许您编写可以映射到本机JavaScript对象顶部的类，以便为这些对象的属性和其他扩展功能轻松提供访问器方法。

有关详细信息，请参阅此链接： JavaScript Overlay Types

因此，您可以通过AJAX调用从后端返回JSON编码数据，将其解析为JavaScript对象，然后使用您创建的覆盖类通过GWT Java代码访问数据。或者，当您渲染页面时，您可以将静态配置数据呈现为JavaScript对象，并通过此机制读取它，而不必执行AJAX调用来获取数据。

Answer 3

如果您了解JAVA，并且拥有可以托管它的地方（如tomcat或glassfish容器），我建议的不仅仅是使用Ruby作为后端。主要原因是，您可以共享所有对象，并使用内置的RPC机制。我已经完成了很多我们的项目，这是一个巨大的节省时间，更不用说代码不容易出错，因为你不会将你的java对象转换为任何东西，然后再转回。

之前我已经将我的GWT与Rails相关联，使用Rails中的to_json函数然后在GWT中读取JSON。这一切都得到了支持，但它比JAVA中的后端更令人讨厌。

当然如果你有便宜的托管，那么Java容器几乎是不可能的，在这种情况下我会认为Rails将是下一个最好的东西。

Answer 4

GWT质量非常高，社区很棒。但是你需要知道CSS，如果你想调整事物的外观（你会） - CSS可以做很多布局，就像你想要的常规网页一样。像GWT-ext或ExtGWT这样的图书馆可以提供一些帮助，因为它们具有令人惊叹的“开箱即用”外观但价格（您的应用程序的额外尺寸）。

Answer 5

您可以使用GWT在Java中编写所有代码，并且可以将现有的第三方JavaScript库与其集成。这很好。我从来没有使用过RoR，所以不能对此说些什么。

Answer 6

如果你有Java经验而不是Javascript / CSS经验，那么GWT将成为救星（当然，除非你想学习它们）。 CSS有很多细节。花费半天时间修复仅在IE6中发生的2像素错位并不罕见。

我不确定将ROR用于后端是多么容易......我确信，有可能，因为GWT ajax通信只是servlet。但它们为来回传递Java对象提供了一些非常好的功能，如果您的服务器不使用Java，则无法使用它们。

Answer 7

我最近写了一些the disadvantages of GWT。主要的缺点是：应用程序某些部分的更改部署周期较长，学习曲线相当陡峭。作为一名经验丰富的Java程序员，第二个应该是一个问题，如果你使用一个单独的后端，第一个也会减轻（因为当你更改应用程序的'服务器'部分时，主要需要完全重新部署）。

Answer 8

GWT是一个很有潜力的精彩框架。但请记住，它仍然是新的。有一些未解决的错误可能真的让你烦恼，而且他们通常需要丑陋的解决方法才能过去。社区很棒，但你可能迟早会遇到一些Google无法回答的问题。

但是，嘿，我说去吧。 GWT的潜力很大，我敢打赌它的未来会很光明。

Answer 9

你绝对应该将GWT用于一个新项目（在旧项目中也很容易使用）。

我的经验是学习和使用的速度非常快。编译好的javascript代码比手工编写的任何代码要好得多，而且它的工作也很快。

另一个好处是可以调试你的代码（仅使用javascript就可以了）

Answer 10

此博客收到了许多有经验的GWT用户的意见，并有一些很好的讨论点。我个人拥有丰富的UI框架经验。我要加两分钱。让我们看看 基本 GWT的优点和缺点

基本优势

GWT将网络层编程带到JAVA。因此，Java的明显优势开始发挥作用。它将提供面向对象的编程。它还将提供出色的调试和编译时间检查。由于它生成HTML和Javascript，它还能够隐藏其生成器中的一些复杂性。

根本缺点

缺点始于同一声明。 GWT将Web层编程转换为JAVA。如果您了解JAVA，可能您永远不会寻找替代语言来编写业务逻辑。这是自给自足的。但是在编写JAVA应用程序的配置时。我们使用属性文件，数据库，XML等。我们从不将配置存储在JAVA类文件中。仔细想想，为什么会这样？

这是因为配置是静态数据。它通常需要层次结构。它应该是可读的。它永远不需要编译。它不需要JAVA编程语言的知识。简而言之，这是一场不同的球赛。现在的问题是，它与我们的讨论有何关系？

现在，让我们考虑一下网页。您是否认为我们在撰写网页时会编写业务逻辑？绝对不。网页只是一种配置。它是分层容器和字段的配置。我们需要为将从网页捕获和显示的数据编写业务逻辑，而不是创建网页本身。

上一段发表非常强烈的声明。这将解释为什么基于HTML和XML的网页仍然是最受欢迎的网页。 XML是编写配置的最佳业务。框架必须允许将Web页面与业务逻辑（MVC框架的目标）明确分离。通过这样做，网页设计师将能够运用他的可视化和艺术技能，通过配置XML而不必担心编程语言的复杂性来创建外观精美的网页。开发人员将能够利用他们最好的业务JAVA来编写业务逻辑。

最后，让我们直接谈谈这些影响。 GWT打破了这个原则，所以它必然会失败。开发GWT应用程序的成本非常高，因为您需要多模式程序员来编写网页。所需的外观和感觉将很难实现。由于不必要的编译，修改网页的周转时间将非常长。最后，由于您在JAVA中编写网页，因此很容易使用业务逻辑来破坏它。在不知不觉中，你将引入必须避免的复杂性。

Answer 11

您还可以考虑使用Grails（“Groovy on Rails”），它可以为您提供Rails框架和Java VM的使用。

Answer 12

我们的团队最近提出了同样的问题，我们选择使用GWT，特别是因为设计人员插件使得GWT的工作更容易被团队中的非Java专家访问。无论谁做出这个选择，只要注意你不要使用GWT Designer插件！尚未更新（至少在一年内，显然）创建与IE8兼容的GWT应用程序。

我们的团队几乎完成了我们的应用程序布局，这些布局在Chrome，FF和Safari中完美运行。然后他们在IE中爆炸了。 IE 7会加载部分页面（但不包括复合包含），IE8甚至无法加载应用程序。它只是挂了。

设计器插件具有允许用户添加不兼容IE的CellTable小部件的按钮（CellTable，DeckPanel，水平面板，垂直面板等）。如果在没有设计人员帮助的情况下必须在java中重新完成布局，这些将导致剧烈的痛苦。

经验丰富的GWT用户喜欢它，但设计师插件会杀了你。