8

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

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

4

9 回答 9

17

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

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

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

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

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

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

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

于 2009-10-02T20:12:11.983 回答
10

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

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

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

于 2010-01-31T23:18:10.120 回答
3

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

于 2010-04-29T19:11:24.563 回答
3

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

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

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

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

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

换句话说，您几乎可以忘记 Javascript 和 HTML。

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

于 2009-07-29T20:37:43.067 回答
0

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

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

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

于 2013-07-03T09:55:15.347 回答
0

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

于 2009-08-17T20:16:47.650 回答
0

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

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