Ant*_*bbs 8 gwt wicket web-frameworks
除了Wicket简单性的论点(即Wicket是一个更简单的系统IMHO)和GWT在客户端的响应(GWT的客户端状态和JavaScript - 可能是复杂的客户端代码)和GWT更大的扩展潜力,有什么争论使用GWT而不是Wicket？
就个人而言,我做了很多Wicket开发,但很久以前只是快速浏览了GWT.
tet*_*suo 17
基本上,优点是GWT是构建基于javascript的客户端的工具,因此,如果你想要一个基于javascript的客户端,它最适合.
Wicket以服务器为中心,虽然它可以很容易地将javascript嵌入到无状态页面中,但服务器端状态处理是更自然的方法.
必须注意的是,架构非常不同.
使用GWT,您的架构变成客户端 - 服务器,浏览器上的胖客户端,调用服务器的"过程"(服务),发送和接收数据.
使用Wicket(以及其他以服务器端为中心的组件框架,如JSF和Tapestry),架构是一个更"传统"的3层架构,发送和接收的是页面或页面片段,而不是纯数据.
虽然你当然可以将两者结合起来以适应其他架构,但它根本不是很自然.
人们倾向于关注"哪个更容易使用"(这完全是主观的,取决于你的背景),或者"更美丽,有更多组件",但是人们不应该低估建筑差异,这会影响你的方法必须采取处理安全性和可伸缩性等方面.
Eel*_*lco 10
在过去的几个月里,我参与了一个基于GWT的项目.多年来,我一直是Wicket开发团队的一员,期待着改变,并期待GWT(我一直吹捧为另一个优秀的Java框架).
老实说,在与GWT合作时我感到很失望.我觉得 - 事实上我的整个团队 - 生产力受到了很大的打击.从理论上讲,GWT很棒.但是当你考虑到框架的怪癖和局限性时,平庸的错误报告(特别是涉及序列化错误时),编译时间长(3到10分钟之间,我们的项目甚至还不大),事实上,当所有的事情都说完了,你仍然需要测试所有浏览器并找到调整和解决方法,事实上它产生了巨大的初始下载(几乎是MB,我们正逐渐减少,但有很多努力)等,我觉得Wicket更容易和更快地工作.
我不讨厌与GWT合作.它仍然比大多数Java框架好很多.只是因为我对它的期望更多; 我甚至预计它可能比Wicket更好.但最终,它只是不是imho.希望GWT 2.0能够改进很多东西,希望Eclipse插件的一些怪癖也能很快得到理解.
在我看来，GWT 的最大好处是允许您使用一种编程语言 - Java，并享受它带来的所有好处。
它们与 CSS 一起构成了一对强大的组合。
换句话说，您几乎可以忘记 Javascript 和 HTML。
这是否是一个优势主要取决于您的技能和要求。我们内部也进行过同样的辩论，最终一个团队选择了 Wicket 和另一个 GWT。