I will have to look into this further. My original posting was talking about GWT 1.4. We just recently upgraded to 1.5, but I haven't looked too much into GWT 1.5 specific features yet.
On Sep 21, 10:20 am, Reinier Zwitserloot <[EMAIL PROTECTED]> wrote: > 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- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
