使用 Google Web Toolkit (GWT) 时的主要缺点是什么答案

【问题标题】：What are the main downfalls when using Google Web Toolkit (GWT)使用 Google Web Toolkit (GWT) 时的主要缺点是什么
【发布时间】：2011-06-30 06:06:32
【问题描述】：

经过许多 RIA/Ajax 框架之间的长期争论，我们最终选择了 GWT。在阅读它时，这个框架似乎可以很好地轻松完成所有事情。但就像任何技术一样，总会有不利的一面，我们很难学习它们。

使用 Google Web Toolkit (GWT) 时的主要缺点或问题是什么？

（例如：后退/前进按钮支持、响应时间慢、布局定位、JavaScrit 错误等）

到目前为止，我从回复中得到以下信息：

简单 UI 的大量代码
编译慢

谢谢

【问题讨论】：

“要点”是什么意思？
我的问题不清楚。我只是改写了。
这就是使用 GWT 的所有缺点吗？ 1) 冗长的代码 2) 编译速度慢...我将在这个问题中添加 Tag (Flex, ext-js, JSF ) 让一些具有不同背景经验的人。

标签： silverlight apache-flex gwt jquery extjs

【解决方案1】：

前段时间我用GWT做了一个原型app，发现编译java到javascript的时间很长。我们编写的每一行代码都显着增加了编译时间。

我只是对代码不满意，编译测试阶段随着时间的推移越来越慢。

关于编译器的另一个问题：How do I speed up the gwt compiler?

【讨论】：

你没有提到你使用的是什么版本。编译时间一直在稳步改进，包括快速和肮脏的草稿编译。另外，如果您正确使用开发模式，那么您根本不需要经常进行编译。
根据我的经验，非常很少需要编译成 JavaScript。开发模式可用于大多数操作系统上的大多数浏览器，其行为非常接近（几乎 100%）最终编译结果（性能测试除外）。此外，通常不需要重新启动服务器。浏览器刷新（用于客户端更改）或server reload 几乎总是足够的。
另外，您甚至可以通过附加一个 Java 调试器来进一步改进开发周期，它甚至可以在客户端代码上工作。（与调试器一样，这种技术显然不适用于所有类型的代码更改）。

【解决方案2】：

我认为主要的缺点是 GWT 通常需要编写大量代码来完成简单的任务（但每个版本都会变得越来越好）。另一方面，它在开发复杂的自定义小部件方面表现出色。在几个项目中，GWT 被证明在性能方面非常好，并且没有很多错误 - 在跨浏览器支持 imo 方面非常好。

【讨论】：

【解决方案3】：

我已经使用 GWT 将近 2 年了。虽然我可以说我是 GWT 的狂热分子，但有些问题应该知道......

正如其他人所说，JavaScript 编译速度很慢。我的应用程序需要将近 4 分钟的核心 i7 CPU、8 GB 内存。生成的 JavaScript 的总大小约为 5 MB。但是由于开发模式，不需要经常编译为 JavaScript。
GWT RPC 在开发模式下非常慢。它比托管模式慢 100 倍。这对我们来说是一个很大的问题。正是因为这个原因，我们才考虑放弃 GWT。开发模式下 GWT RPC 性能缓慢的原因是序列化。在开发模式下，String 以外的类型的序列化速度非常慢。我们确实实现了自定义序列化，它比 GWT 内置序列化快近 30 倍。
声称编写 GWT 应用程序只需要 Java 知识只是一种幻想。你应该有关于 CSS 和 DOM 的可靠信息。否则，您将花费太多时间来调试您的用户界面。
您应该考虑只能使用 JDK 的一小部分来实现 GWT 应用程序。反射不可用；您应该使用第三方库，例如GWT ENT，或者编写自己的generator 进行反射。
另一个应该考虑的警告是 GWT 编译器生成的 JavaScript 的大小。大多数 GWT 应用程序由单个网页组成，这与多页的传统 Web 应用程序不同。因此，加载应用程序需要大量时间。尽管可以通过使用多模块方法和代码拆分来缓解这种情况，但使用这些技术并不总是那么简单。
对服务器的所有调用都是异步的。你应该让自己适应编写异步代码。异步代码的缺点是它比等效的同步代码更复杂，可读性更差。

【讨论】：

非常感谢您分享您的经验。这些对我们来说都是非常宝贵的。

【解决方案4】：

以下是我对失败的看法：

如果想在large applications 中有效地使用 GWT，学习曲线会很陡峭，因为与 GWT 相关的大量高级约定。
- Model View Presenter 范式 - 实际上 GWT 网站上提出了 2 种不同的 MVP 方法。
- UiBinder
- CellWidgets
- Editors
- Activities and Places的概念
- RequestFactory
- AutoBeans
在设计整个应用程序时，异步请求需要不同的思维方式
编译时间长，它不会像完整构建那样影响开发模式（所有浏览器和语言的所有排列都已编译，对于大型项目可能需要数小时）。 JRebel 可以稍微降低开发模式重启的要求。
单元测试问题 - GWTTestCase 启动时间过长以至于无法用于单元测试。然而，多亏了 GWTTestSuite，它可以很好地用于集成测试。感谢保持干净的 MVP，也可以unit test Presenter logic by mocking Displays（见我的回答）。
需要一定的经验来决定具体的逻辑是在客户端（编译成 JS）还是服务器端实现。
当然还有一些小错误，尤其是在编辑器和请求工厂等新功能中。它们通常会在新版本中快速解决，但是当您遇到一些 GWT 问题时可能会很烦人。无论如何，最后的失败适用于我迄今为止使用的任何 Java 框架。 ;)
客户端缺乏反射，这可以通过Deffered Binding and Generators 解决，但这是另一个需要学习的约定。

如果我要开始新的 GWT 项目，我会：

添加对 Google GIN 库的依赖（遗憾的是，它目前不适用于 GWT 2.2，但应该很快兼容）。
用LayoutPanels设计总体布局
根据场所和活动的概念构建应用程序“流程”。
将所有地点放入单独的 GWT 模块（通用导航参考）
将每个 Activity 放入自己的 GWT 模块中（它可以在以后的 application code splitting 中提供帮助）
将 Activity 视为胶水代码，其中注入了 GIN 的 View 和 Presenter 提供程序
设计与 RequestFactory 兼容的数据实体
使用 UiBinder、MVP 和 Editors 框架创建所有数据编辑器
在 Presenters 和活动中使用 RequestFactory（以获取要显示的初始数据）。
使用 GIN 注入每个已识别的常见组件，例如标准日期格式等。

spring roo 工具可以为标准应用程序元素生成大量基于 GWT 的代码。

【讨论】：

非常感谢您分享您的经验。

【解决方案5】：

作为耶稣诞生的粉丝... 我更喜欢 JQuery 而不是 GWT，因为它很容易制作动画或完成复杂的任务，而无需编写很多类..

【讨论】：