GWT与Apache Wicket

这对橘子来说非常棒。

这个wiki条目总结了一些相似之处和差异，以及一起使用它们的战略的开始，我认为这是一个有趣的想法。

Wicket主要是一种服务器端技术，具有一些内置的Ajax支持以及用于在更多Ajax中进行连接的钩子。 它不像GWT那样把Java转换成JavaScript。 它维护GWT在客户端维护状态的状态服务器端。

两者都是基于组件的，而且对我来说有一些Swing开发的感觉（尽管Wicket似乎并不像Swing那样感到至少有一个其他受访者）。

我已经在一个大型项目上使用了GWT（1.x和2.x）和Wicket（1.4,1.5）几年了，而且这两个框架都有其优点和缺点。 他们都很酷，很好， 如果他们用于他们已经设计的 。 但是，您可以轻松地将它们混合在一起，以充分利用这两者。

• Wicket对CRUD网站非常好，功能强大，页面设计（HTML）和Java代码之间有很好的分离。 只要你不需要强大的客户端功能，就可以很好地完成它的工作，而且代码冗长：但是这是要付出巨大代价的奖励：没有什么“魔力”。 重构和组件化就像一个魅力。 对于大型项目，它可以很容易地解耦 ，并且设计得很好，可以与大型团队一起工作 ：人们可以专注于提供一组很好的核心组件，其他的在表示层上，等等。唯一的缺点是在客户端的复杂行为，你仍然需要掌握Javascript ， 并且自己将Wicket和Javascript混合起来可能会变得相当复杂 。

• 如果你真的需要在你的客户端（类似GMail的应用程序） 丰富的行为功能， GWT是很好的。 GWT的主要问题是在纸上看起来太好了（“java中的所有东西”范例），但是它并没有履行它的承诺。 它不能很好地扩展 ：对于提供一组功能的小模块，GWT很不错，而不适用于大型应用程序。 编码/编译/调试周期相当长，而且当模块尺寸变得太大时，就成了一个负担。 另外，它不支持在同一模块上并行工作的大型团队。

总之，我建议人们不得不选择：

• 在真正需要的时候谨慎使用GWT，保持模块尺寸小 ，不要完全用它来构建一个完整的应用程序;
• 其余的使用wicket（Wicket真的很好！）。
• 为了将两者混合在一起，可以使用Wicket的强大组件功能以“wicket方式”（ GWT模块成为一种特殊的Wicket组件 ）模块化GWT代码，并且再次保持GWT小 。

现在使用GWT 2，与Wicket相比有什么优势？

这个线程已经运行了6年，GWT大多停滞不前。 Wicket似乎更积极地发展和支持。 任何人对Wicket或其他选项有更新的意见？

Wicket是基于服务器的框架..它比GWT更类似于JSF。 GWT在概念上与Swing类似，我是前摇摆开发者，从swing到gwt非常容易。 但是我不能对Wicket或JSF说同样的话。