Hi, > sounds like you want to rewrite gwt but using wicket model for > handling markup instead of layout manages which is what gwt uses. it > is probably much easier to write a library for gwt that implements the > wicket markup model rather then the other way around...
Like this http://code.google.com/webtoolkit/doc/latest/DevGuideUiBinder.html? >> script within the generated HTML. That does not suits. And BTW gwt compiler >> is slow as hell (minutes!!!), We have compile times from 10 minutes up to over an hour. No kidding. >> how people are happy developing GWT applications? Definitively spoils the fun. Especially because in our experience, though GWT has the promise of write once for all browsers, you still need to do quite a bit of testing and tweaking to make sure everything looks good in different browsers. Also not very helpful is the fact that the Google Eclipse plugin uses the jars copied to a war/libs directory rather than the class path you define for your project, which cost us a lot of time because we have our projects broken up in smaller pieces (dependent projects), and every little change we have in one of the dependent libs means having to create a build for them, and then copying them to the war/libs dir. Hopefully this will be fixed some day. And then there is that if you don't optimize, you easily end up with over a MB initial download (just a medium sized application). Oh, and I never would've guessed how much we depend on introspection to take the plumbing code out until you have to do without as in GWT. Anyway, it's not all bad. The improvements for 2.0, including UiBinder, look good, and the code we're ending up with is, though more bloated than with Wicket, quite neat (good separation of concerns, testable, componentized, etc). I feel we took a substantial hit in developer productivity using GWT for our new projects rather than Wicket, and I would probably pick Wicket again for my own projects, but compared to the alternatives out there, GWT is still a pretty good framework, where the larger the scale (development wise) of your project, the larger the pay off is. >> The next generation of HTML/JS would evolve towards client programming >> capabilities. I like Wicket for its full freedom of HTML (contrary to GWT) >> and I would like to use similar model when programming rich web client >> applications. And it is less about the Wicket way of splitting html and >> java. It is more about binding to dynamically loadable data with any deep of >> structure displayed on users demand. The GWT way would require to program it >> in any way when Wicket does it transparently. Yeah, another thing I miss is lazy-ness... but that'd be hard to reproduce when you would move from a request/ response model to JS driven. >> Another story is authorization >> that can be done transparently. But web development evolves and client side >> programming becomes more and more demanded. I tried to think about how >> technically we could use the best of both worlds. >> >> What do you think about all that? Sounds to me like enough ideas to base a new framework on ;-) Personally I think that Wicket should keep focussed on the programming model we have now. Drastically changing that just means building another framework, and we can learn from other frameworks that that's just not a very good idea. Also, I wouldn't really have an idea how to implement this without basically copying GWT, which is probably hard to beat at it's own game. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
