用于大规模应用的 GWT答案

【问题标题】：GWT for large scale applications用于大规模应用的 GWT
【发布时间】：2012-04-04 10:35:32
【问题描述】：

我听说 Google Web Toolkit 对于页面超过 5 个且布局通用的网站不太适用。真的吗？我们至少有 100 个子页面和一个在 CSS 中定义的通用布局。今天使用的是 PHP，但我们将转向 Java 前端，无论是 Spring MVC 还是 GWT。我们正在使用 som jQuery AJAX 和其他 jQuery 组件，例如 jqGrid。我们还有一些 .swf 电影和融合图表。选择 Spring 与 GWT 结合是一个不错的选择，还是带有 jQuery 库的 Spring MVC 对我们来说是一个更好的选择？

【问题讨论】：

您从哪里听说 GWT 不适合 超过 5 个页面和通用布局的网站？此外，GWT 不是为网站网站设计的，而是为网站 应用程序 设计的，如果这可以帮助您做出选择的话。

标签： model-view-controller gwt jakarta-ee smartgwt

【解决方案1】：

现在不是这样。早期的 GWT 版本确实存在一些可伸缩性问题（例如 IE 中的 JS 代码大小问题 - http://code.google.com/p/google-web-toolkit/issues/detail?id=1440），但从 GWT 2.0 开始，您就没有任何限制了。

此外，最新的 GWT 版本支持将项目拆分为可在需要时动态加载的部分的功能。请参考https://developers.google.com/web-toolkit/doc/latest/DevGuideCodeSplitting 了解其工作原理。

还要考虑到，由于 Spring 是 Java，您可以在服务器端和客户端之间共享类。此外，Java 在 IDE 中有很好的支持——所有类型的重构都可供您使用（如果您使用 jQuery，那就不太方便了）。

所以 Spring+GWT 看起来是更可取的选择。

【讨论】：

【解决方案2】：

GWT 不是一个从头开始构建任何 web 应用程序的通用框架。当您在客户端有很多复杂的逻辑时（图像编辑、实时协作、图表绘制、游戏、复杂的报表构建等），它非常有用。但是所有这些都可以在没有 GWT 的情况下完成。 GWT 可以在以下情况下使用：

您的团队讨厌/不喜欢 JS（并且无法使用 JS 构建任何复杂的东西，只是因为他们讨厌 JS）
您的团队在 Java 方面经验丰富
您的团队了解所有这些浏览器相关内容的工作原理（HTTP、JS、DOM、CSS 等）
在这个项目中会有很多逻辑在客户端运行

我见过很多完全使用 GWT 构建的大型项目。他们中的一些人永远不应该使用 GWT，因为他们没有理由以这种方式使用它。对于大多数项目，仅将 GWT 用于应用程序的某些部分就足够了。

选择取决于您的团队和您正在进行的项目。如果您的团队无法真正看到 GWT 将为项目带来什么好处，那么您不应该使用 GWT。

【讨论】：

【解决方案3】：

我们的企业级应用程序同时利用了两者，我们对结果非常满意。 GWT 是一个强大的工具包，可以将开发时间降低几个数量级。也就是说，GWT 仍然不能很好地处理一些事情，或者只是简单地不适合（这没关系......这就是 Spring MVC 就在附近的原因）。我们让 GWT-RPC 直接访问 Spring 服务，而且效果非常好。

虽然我们的项目是一个真正的网络应用程序，而不是一个网站。我们使用跨越所有“页面”的统一设计（使用DockLayoutPanel 并仅替换center 使这非常容易）。

IMO，谁告诉你 GWT 不适合在众多“页面”上进行一致的设计，这简直是疯了……

【讨论】：

【解决方案4】：

我认为，在肩垫和 Jan Hammer 的合成器很流行的时候，Frederic Brooks 已经驳斥了任何关于 GWT（或任何其他方法）将开发时间缩短一个数量级的说法：http://en.wikipedia.org/wiki/No_Silver_Bullet。

但是说真的，如果您是 PHP 商店，那么迁移到 100% Java 将是一项巨大的投资，不能掉以轻心。

【讨论】：

我不同意 Brooks 揭穿 GWT 降低开发时间的说法。他的评论是“无论是技术还是管理技术，都没有单一的发展，它本身就有望在十年内提高生产力、可靠性和简单性一个数量级。”他说，在 1989 年，他说十年内不会发生这样的发展。二十多年过去了，因此他的陈述是真实的并且GWT提供了他所说的不会发生的确切情况。
我理解他的话的意思是，在广泛采用后的十年内，没有哪一项技术能够将生产力提高十倍。并不是说人类的聪明才智会在十年后突然发生巨大的飞跃。技术的组合可能会成功。但是 GWT 本身是否真的让你的工作效率提高了十倍？我不是说不能。我喜欢 GWT，但它不会创造奇迹。
奇迹？不会。生产力提高了 1 倍，是的。如果不出意外，我花了 100% 的时间 编写特殊情况代码以适应平台/浏览器特性。 GWT 通过创建多个排列来处理这个问题，每个（统计上显着的）浏览器一个排列，有效地消除了计划和反应不同浏览器对相同代码的反应所花费的时间。
我同意。我记得在 2000 年不得不处理 IE3 和 Netscape 4 之间令人抓狂的差异。从那以后情况肯定有所改善。

【解决方案5】：

就我对 GWT 的体验而言，我唯一不好的体验是 GWT 编译速度慢，原因是很多排列。我们的应用程序有 20 多种语言要支持，对于特定的浏览器乘以 6 会产生 120 种排列，结果证明性能非常糟糕。

但这不是真正的错误问题，因为您将主要使用开发模式，即时代码更新，并且您可以使用减少浏览器和语言集的特殊编译单元（甚至一种语言和一种浏览器 =>一个排列，如果你愿意）。

因此，就我而言，使用 Jenkins，我们在夜间完成了大型产品目标的完整构建，部署在 QA 平台上，以便 QA 团队测试每种浏览器语言组合。每次提交时，都会在开发验证平台上部署一个精简的构建版本（在我们的例子中是 1 个浏览器和 2 种语言）。

GWT 绝对是大型应用程序的绝佳工具。 ;)

【讨论】：

GWT 超级开发模式这次已将每次刷新时间缩短到大约 4-6 秒。很容易管理。