The central purpose of GWT, as I understand it, is to make writing apps 'like gmail' easier. In other words, all these things are either outright annoying or inconvenient with GWT, or at the very least no easier than with vanilla javascript:
- any website that has more than one logical page. e.g. all of gmail is just 'gmail.google.com'. There's not gmail.com/message/12345. Wave is similar in that respect. - Working with mostly static content and injecting only a few dynamic behaviours. - Working close to the core platform; letting the server render some HTML, grabbing it via XML, and just stuffing it via .innerHTML into a div container. On the other hand, these are very niche applications where GWT shines: - working with huge code bases for a single website: GWT has namespaces, static type checking, and the most aggressive code reduction strategy available today. Because of java's manifest, nominal, static, strong type system, as well as GWT's atomic compilation process (no reflection or class loading of any sort) GWT can easily determine if a given method (or even an entire classworth) is never actually called on, and if not, just eliminate it wholesale. That kind of source code base reduction is pointless everywhere, EXCEPT the web, especially for an app like gmail that is loaded gazillions of times a day. - As mentioned, size reduction. Especially for complicate web apps, writing it in GWT means smaller downloads. This really is niche; if you're building a new web service and squeezing the last couple of bytes out of the download is important to you, then you're doing something wrong. google of course does, and should, worry about such things, and GWT reflects this. GWT also reduces size by way of compressing all images into a single one, rolling all JS into a single file, and even loading _just_ the code that is tailormade for the target Browser AND language. (With 10 languages supported and 4 browsers, for example, GWT produces 40 files, one for each combo, and uses a small dynamic loader that gives just the right one to the user agent). - unifying server and client code bases. You can put your form validation code in a common package and call it from both your GWT and your server code. There are tricks available to try this with javascript (from writing in an HLL and translating this to BOTH java and JS, to using Rhino to run the JS code server-side), but in GWT its trivial, for obvious reasons. It goes much beyond this though; for example, the code that decides where an email should be rendered in a gmail discussion tree (is this a reply to this email, or that email? This is non-trivial) can exist on both ends; that way, when new email come in, the server just has to hand the client the content, and let the client sort out where it's supposed to go. When building the database indices so that an entire thread can be retrieved quickly, that same code runs server side. Here's my advice for building web services: 1) Start with JQuery, and keep it simple. 95% of all projects ought to be html, css, and jquery, with something simple on the backend. 2) Only if you really know what you are doing, and you have some very non-standard requirements, look elsewhere. GWT is a good place to look. So is webstart/fx. (and similar technologies, but, hey, this is a java-centric newsgroup!) On Jun 27, 5:27 pm, Jess Holle <[email protected]> wrote: > I concur with Dick in one respect here: > > Google seems to be working /really/ hard to use Java to author client > software while avoiding actually using it on the client -- at least with > GWT. > > While GWT is really cool for those who want to write Java, not > JavaScript, it is essentially a giant workaround. The real solution is > better Java Plug-In penetration and just using it. Java 6 Update 10 and > later are actually rather good. > > GWT predates Java 6 Update 10 and I can understand that even now Google > may feel the Plug-In is not a feasible alternative (i.e. that they > really can't help drive this into clients despite Chrome, etc). I do > sometimes wonder whether Google even /wants/ Java on the client -- as > they have more influence and traction in the [D]HTML space. In any > event, I believe Google /could /expend a little of their influence to > help Java (and JavaFX) become a real force on the client -- but they > clearly have chosen not to attempt that. > > Then there's Android. I have to really applaud Google here in one > respect -- Java ME is a throwback to ancient Java history and is just > begging to be by-passed. Specifically, there's no support for Java 5 > language features in ME and no plans whatsoever to add these! On the > other hand, Google went a lot further to develop their own set of client > libraries rather than using any existing client libraries -- and thus is > creating another splinter UI platform space like SWT did before it. > > -- > Jess Holle --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
