现在有了 GWT 2，与 wicket 等相比有什么优势？答案

【问题标题】：Now with GWT 2, what are the advantages over wicket and likewise?现在有了 GWT 2，与 wicket 等相比有什么优势？
【发布时间】：2009-07-29 13:48:23
【问题描述】：

除了 Wicket 的简单性（即 Wicket 是一个更简单的系统恕我直言）和 GWT 在客户端的响应能力（GWT 的客户端状态和 JavaScript - 潜在的复杂客户端代码）以及 GWT 更大的扩展潜力的论点之外，什么是使用 GWT 而不是 Wicket 的论据？

就我个人而言，我做过很多 Wicket 开发，但很久以前才快速浏览过 GWT。

【问题讨论】：

标签： gwt wicket web-frameworks

【解决方案1】：

优点基本上是，GWT 是构建基于 javascript 客户端的工具，因此，如果您想要基于 javascript 的客户端，它最适合。

Wicket 以服务器为中心，虽然它可以很容易地将 javascript 嵌入到无状态页面中，但服务器端状态处理是更自然的方法。

必须注意，架构非常不同。

使用 GWT，您的架构变成客户端-服务器，即浏览器上的胖客户端，向服务器调用“过程”（服务），发送和接收数据。

使用 Wicket（以及其他以服务器端为中心的组件框架，如 JSF 和 Tapestry），架构是更“传统”的 3 层架构，发送和接收的是页面或页面的片段，而不是纯数据。

虽然您当然可以将两者混合以适应其他架构，但这并不是很自然。

人们倾向于关注“哪个更容易使用”（这完全是主观的，取决于您的背景），或者“哪个更漂亮，组件更多”，但不应低估架构差异，这会影响处理安全性和可扩展性等方面所必须采取的方法。

【讨论】：

我认为一个常见的问题是人们确实考虑了可扩展性，但高估了他们对 Web 层的要求，而忽略了它的安全方面。至少我的经验。
我同意，大多数人只是不知道如何处理安全性，并相信它会神奇地“发生”在某处的某些配置中。关于可扩展性，我认为这两种技术都能很好地处理“非 Facebook”的可扩展性，但方法会有所不同。并且使用错误的方法会导致同样丑陋的问题。
有趣的是，“传统”的定义随着时间的推移而发生了变化。多年前，这意味着客户端-服务器（厚客户端）方法。在此之前，它是一个哑终端和服务器（瘦客户端）。现在我们回到了使用 JavaScript 的胖客户端，我想知道下一个瘦客户端架构会是什么样子。

【解决方案2】：

在过去的几个月里，我参与了一个基于 GWT 的项目。多年来，我一直是 Wicket 开发团队的一员，期待改变，并对 GWT（我一直吹捧为另一个伟大的 Java 框架）寄予厚望。

老实说，我对与 GWT 合作感到失望。我觉得——实际上是我的整个团队——生产力受到了很大的打击。从理论上讲，GWT 很棒。但是当你考虑到框架的怪癖和限制、平庸的错误报告（特别是在涉及序列化错误时）、编译时间长（在 3 到 10 分钟之间，我们的项目还没有那么大）时，事实上，当一切都说完了，你仍然需要测试所有浏览器并找到调整和解决方法，它会产生巨大的初始下载（几乎一个 MB，我们正在逐渐减少，但有很多努力）等，等等，我觉得 Wicket 更容易和更快地使用。

我不讨厌与 GWT 合作。它仍然比大多数 Java 框架好很多。只是我对使用它的期望更高。我什至预计它可能比 Wicket 更好。但最后，这不是恕我直言。希望 GWT 2.0 能改进很多东西，也希望 Eclipse 插件的一些怪癖也能很快得到解决。

【讨论】：

在 GWT 2.0 和 UiBinder 方面有过一些（大部分是间接的）经验，我可以确认事情变得更好了。我仍然觉得您需要大量的管道代码来完成使用直接 JavaScript 并不难完成的事情。

【解决方案3】：

将 GWT 与 wicket（或类似的）进行比较有点不公平，因为它们确实来自 2 个不同的阵营。前者是构建 JavaScript 前端应用的框架，后者是经典的 Java Web 应用框架。

因此，以下几点并不像 GWT 与 wicket 那样多，而是当我们决定将 GWT 用于高级 JavaScript/AJAX Web 应用程序时编译的一般列表：

通过允许隐藏 JavaScript 和跨浏览器支持的缺点使用 Java 开发并自动编译为特定于浏览器的 JavaScript 风格（由于泄漏抽象定律，这完全不正确，但这是首先创建 GWT 的主要原因 - 请参阅 Reveling in Constraints）；
Java 是许多 Java 开发人员首选的高级 JavaScript/AJAX UI；
Java 开发环境和工具得到全面支持：Eclipse 插件、调试器、重构、Eclipse 中的托管模式；
模拟对象和托管模式都支持 JUnit 测试；
与 Java 后端 (GWT-RPC) 的干净集成；
相对丰富的 UI 小部件集，具有统一的外观和感觉；
第三方小部件、框架、模式和示例的可用性（仍然有限且愿望清单很长）；
Google 支持推动了框架的广泛接受/普及和快速发展；
具有 1.6+ 和即将发布的 2.0 版本的成熟框架：（事件总线、事件处理程序、具有 MVP 模式的 GUI 架构、编译器优化等）。

【讨论】：

【解决方案4】：

与 GWT 相比，Wicket 的一个优势是 Wicket 可以处理您希望为未启用 Javascript 的客户端提供回退的情况。 GWT 完全适用于 Javascript，Wicket 允许您优雅地降级。

【讨论】：

【解决方案5】：

在我看来，GWT 的最大好处是让您可以使用一种编程语言 - Java，并拥有它带来的所有优点。

与 CSS 一起，它们形成了强大的一对。

换句话说，你可以大部分忘记 Javascript 和 HTML。

这是否是优势主要取决于您的技能和要求。我们在内部也进行过同样的辩论，最终一个团队选择了 Wicket 和另一个 GWT。

【讨论】：

你可以为 Wicket 中的编码提出几乎完全相同的论点..？
不，你不能。您可以在没有 Javascript 的情况下在 Wicket 中编写富客户端应用程序吗？
否 - groups.google.com/group/google-appengine/msg/fe9792729081fc6d。 ATM GWT 直接从 Java 源代码编译，而不是从字节码编译。所以编译器必须扩展以识别 Scala 语法。

【解决方案6】：

对于典型的商业网络应用程序，我可以想到 GWT 比 Wicket 更好的选择的几个原因：

GWT 来自 Google。这可能是不公平的，但拥有一家大型且受人尊敬的软件公司支持一个工具是一个巨大的优势（押注它更安全，更多的书籍和在线资源，更多的第三方支持，更好的 IDE 支持， ...)。
Wicket 等以服务器为中心的 Web 框架已经过时。现代网络浏览器非常强大，而且越来越强大，因此现代网络框架应该可以帮助您利用这一点。
直接用 HTML 和 Javascript 编码永远不会像用 Java 编码那样高效（至少根据我的经验）。此外，还有更好的 Java 代码工具（调试器、静态分析、单元测试和代码覆盖率等）。

【讨论】：

我不同意 GWT 的“巨大”优势。有很多大公司推出了糟糕的框架（例如 JSF 就是这种情况）。诚然，谷歌总体上提供了很好的框架，但归根结底，真正参与其中的人比他们工作的公司更重要。
实际上，在阅读您的其他两点时，我怀疑您对 Wicket 及其目标的了解并不多。
“像 Wicket 这样的以服务器为中心的 Web 框架已经过时了。”您是否尝试过使用 HTML 4 和 JavaScript（是否使用 GWT 编写）构建一个 RESTful Web 应用程序？ HTML 5 将改变一些事情，使其更容易（或在某些情况下可能）。 Wicket 在这里为您省去了很多麻烦。
“GWT 来自 Google。这可能不公平，但拥有一家大型且受人尊敬的软件公司支持工具是一个巨大的优势”。我不明白这一点？ Wicket 来自 Apache，你知道，他们给了我们 Apache HTTP 服务器，部署了最常用的 Web 服务器？更不用说其他一些产品，例如 Tomcat、Ant、Maven、log4j、Apache Commons，仅举几例。
为什么服务器端框架已经过时了？您能以任何方式支持该声明吗？

【解决方案7】：

GWT 背后的天才在于您只使用 java。他们在 RPC 方面做得很好，使得它对程序员几乎是透明的。很多时候，您会觉得自己编写的代码更像是一个桌面应用程序，而不是一个真正定义了客户端和服务器端的应用程序。

【讨论】：

这与wicket的目标非常相似。
是的，这正是使用 Wicket 编写应用程序时的感觉 - 编写桌面应用程序的所有熟悉和轻松。 Wicket 相对于 GWT 恕我直言的好处是，就像在桌面开发世界中一样，将 UI 绑定到 Wicket 中的域模型对象是通过标准方法调用和对象引用来实现的。在 GWT 中，当您将您的 UI 绑定到您的域模型对象时，您必须与一个非常奇怪的床伴一起上床：“对象编组”——如果您喜欢硬着头皮做事，这没关系。

【解决方案8】：

我是 GWT 的新手，但经过一些研究后，我发现 GWT “适合”我的新 Web 应用程序项目，因为它以客户为中心，让我感觉像编写桌面应用程序一样。今天我们有高性能的客户端准备在客户端运行应用程序。我的应用程序可以仅用 Java 完成，而 OOP Java 类使我们有机会为我们的团队构建我们自己的即用型框架。

【讨论】：

【解决方案9】：

我发现 wicket 与 GWT 相比几乎没有其他优势。

GWT 不适用于禁用了 javascript 的浏览器。（虽然这种情况很少见）。如果 javascript 不可用，Wicket 总是回退到正常的 http 请求。
GWT 应用程序是单页应用程序，这使得书签和使用浏览器选项卡有点困难。使用 wicket，您可以选择创建一页应用程序或多页应用程序。如果您愿意，您可以将页面设置为书签。
在 GWT 中，创建自己的组件并不总是那么容易。在 wicket 中，由于您使用的是原始 html、css 甚至 javascript，因此制作自定义组件非常灵活。您甚至可以非常轻松地包装现有的 jquery 或 dojo 组件。
由于 GWT 涉及将 java 编译为 javascript，因此您只能使用 GWT 编译器模拟的 java 类。这可能是限制性的。 Wicket 是一个服务器端框架，你可以使用所有你想要的 java。
使用 GWT 的 wicket 更容易与 CSS 和网页设计师合作。

【讨论】：

Wicket 并不总是回退到正常的 HTTP，因为 Javascript 不可用。只有设计为后备的组件才能这样做。