I really like the idea behind GWT. And striving for a statically typed 'true' OO programming model is what GWT and Wicket have in common.
I haven't build anything with GWT, so my opinions in this respect are what I infer from how I think GWT works. I expect GWT to scale more easily if you plan well for it. Meaning that you probably don't want to end up with a very crowded pages that's very chatty with the server.. in that case Wicket might actually be more efficient (probably a surprise for many) because often times it'll do everything in one request (locality). A few other things I like about Wicket when compared with GWT: - It's just the Java code you work with, nothing complicating like an extra compile step (in GWT's case to JavaScript) or even byte code engineering like many other frameworks do. This makes Wicket easier to debug - though admitted Wicket doesn't have the easiest to follow bowels around due to the magic we have to do to give users a stateful programing experience. - Wicket is very flexible. I've read comments a while back of someone saying Wicket doesn't very well support integrating with other libraries... well, that's just bullocks. Some things will be harder than other things, but you can pretty much take the framework apart at any level and replace with your own ideas, including tags that dynamically create components and stuff. - Wicket is completely dynamic. I've worked on several projects now where we had panels contributed by e.g. domain objects. Maybe not something that appeals to people who take separation of layers ultra serious, but I think it is awesome. I currently use this for functionality that is about surveys. Surveys have questions, and these questions can be anything... free text, multiple choice, but potentially location or color. Questions can contribute their own panels for editing and viewing. So we can decide at some point to e.g. develop a location question, that displays a map, and we could jar the question with the UI with it, plug it in, and no-one ever had to touch other parts of the UI. I love that kind of flexiblity, and it's hard to find frameworks that support stuff like that (though I expect that you can achieve something like this with GWT, I don't expect it to be as straightforward as with Wicket). - It's safe by default. I don't mean hacker-safe, but rather that you never by default communicate sensitive info like IDs (or as with GWT whole objects) with clients. My experience with using other frameworks than Wicket is that we always spent quite a bit of time making sure users couldn't do things they weren't supposed to do (like deleting an object they have no right for), whereas with Wicket based projects the amount of time doing this is zero. I do expect a few things to be nicer with GWT though. Mainly, no worries about scaling (Wicket *is* scalable, but beyond a few servers you'll have to do work for it, while with GWT it's mainly a question of scaling your services and avoid too much chatty-ness), and no worries about detaching models! And these two advantages can be large enough for someone to prefer GWT. I can easily make this email 3 times longer with my perceived pros and cons, but these are the things that spontaneously came up. :-) Eelco On Wed, Apr 8, 2009 at 6:11 AM, Casper Bang <cas...@jbr.dk> wrote: > I was just wondering about the Wicket community's opinion of GWT. It seems > to share many of the positive characteristics as Wicket (focus on code, not > markup) with the major difference/benefit as I see, that is does not > maintain any state on the server. Also, with GWT you seem to get more > readily available components (i.e. http://extjs.com/explorer/). The bennefit > of Wicket as I can see, is that applications potentially degrade nicer and > the programming model hides the Ajax RPC better. Any thoughts? > > /Casper > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
