For example, this is a segment of code that puts a text box into a grid (in this case, as part of a login form):
usernameBox = new TextBox();
As well as GUI stuff, the other thing that it provides is a way to perform RPC, so you can initiate a request when an event occurs, such as a button press, and some time later you get the response and the user interface can be updated accordingly. It supplies all the interfaces to catch the request at the server side, process it, and return the result. All this is done by passing around Java objects, just as you would when working with a purely Java-based system. I believe that it uses something like JSON internally, although I haven’t looked into that much yet.
The point where the pure Java abstraction breaks down is that any classes that are used by the part that is getting compiled into JS must be either in the same package as the rest of the client code, or part of the libraries that are part of GWT. Fortunately, GWT includes all of java.lang and much of java.util so commonly used classes are available. However, care must be taken to convert any exceptions to something that is available to the client code, and to not do things like (as got me at one point) passing an ArrayList containing java.text.Date instances. Mysterious error messages occur if you do this. The silver lining of this is that it forces you to do proper separation between the code that produces the data and the code that displays it.
There is a fair amount of things that aren’t included that would be in a more mature GUI toolkit, however all the important stuff (that I’ve needed, anyway) was there. The trickiest part that I encountered was getting file uploads to work. It turns out that it’s not possible to do this directly from JS, as it’s not desirable to give scripts access to files, and so a regular HTML form must be used. However, the problem with forms is that clicking on the ‘Submit’ button causes a POST to go to the webserver, which requires loading new content and restarting the app. This was avoided by using a custom component to create the form, and having it target an invisible IFRAME. This, along with polling the server to get the state of the transfer makes for a nice upload interface. It’s not perfect (I’d like to avoid the polling of the server), but it works well enough.
GWT isn’t useful for building full-on websites. As all the content is dynamically created, you won’t get any sort of keywords visible to web crawlers, and your accessibility is out the window. If your needs are simply to produce a nice-to-use web-based application, it makes things quite easy.
Want to sound like a real geek? Call it ECMAScript. ^_^
I just can’t help but get sracastic w.r.t to the above comment.
That would mean C# and some of the new breed of OOP languages are ALSO RELATED to Java. Sure.
And so is Perl, Python, Ruby, etc etc. I guess they are ALSO RELATED to Java. Absolutely!
Now that is a strong relationship! Unfortunately its still not a reality!
And so is all the other 15, 234.5 programming languages out there!
@Rajesh: I was going to make the same points, but didn’t get around to it.
In fact (well, unverified, from memory, fact), Java and JS syntax comes from C, which comes from Algol-60. Also, the way they do objects is totally different. Java uses the class-object way of doing things (such as Smalltalk does), whereas JS uses a prototype-object model. I don’t consider this a relationship either 🙂
As for your other points, I think you’re quite correct.