GWT used to lock you in, but the GWT 1.5 release (very recent) combines something called 'Javascript Object Overlays' and Widget classes that can wrap existing HTML widgets. Add to this the release of the gwtQuery library, and you're not locked in at all, and you can use GWT as a glorified 'add extra features only'-style toolkit. If you're familiar with jQuery - that, but with java code.
On Sep 21, 4:18 pm, Jack <[EMAIL PROTECTED]> wrote: > GWT doesn't lock you in as much as you'd think. > > We develop largely content oriented web apps using the traditional > approach of HTML authors writing HTML and Java developers working on > the back end. We were able to use GWT to add dynamic widgets to our > site without any problems. You do need to have a reasonably > understanding of the GWT architecture though. > > I can provide you with more details if you want. > > On Sep 21, 12:10 am, Alan Kent <[EMAIL PROTECTED]> wrote: > > > Listening to this group over the years has been great. Every so often I > > sit down a rethink what technologies a new project should use with the > > following (debatable) goals: > > > * Try to keep technology count down so there is less for team > > members to learn > > * Try to keep UI widely accessible > > * Develop modern feeling UI > > * Make sure system is scalable for large numbers of users (this is > > my requirement - not true for all applications) > > > The following represent my current thinking here - feel free to rip to > > shreds! ;-) > > > * Flex - great for rich UI's, but not available from iPhone (at > > least) - so its not a universal technology yet > > * JavaFX - may be great for rich UI's, but won't be available on > > iPhone as there is no Java there (at least not yet) > > * Therefore, AJAX using JavaScript etc seems best bet still today > > for wide platform rich UI (I guess this is why Chrome for example > > has pushing JavaScript performance improvements so much) > > * Supporting lots of users means keeping too much state on the > > server is bad - uses up too much resources > > o IceFaces seems to keep whole render tree on server, and ship > > differences to web page. Might be easy to program, but > > requires lots of server resources. > > o I could be wrong, but my experience with JSF in general > > gives me the feeling of resource hungriness. > > o Therefore, its better to keep state information on client > > and (try to) make all client->server requests stateless > > * GWT I recall some comments (on this list? elsewhere?) saying its > > quite good, but locks you in (if you want to do something its not > > designed for, you can hit a dead end). I am a little uncertain > > here how true the comments are having not used GWT for any large > > scale project. > > > That leaves me with the feeling of trying to write stateful client > > applications in JavaScript (using existing toolkits and libraries > > around) making stateless requests (when possible) to a load balanced > > server (possibly using GWT, otherwise doing serious development in > > JavaScript natively). > > > Constructive ridicule welcome! > > > Alan --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
