I'm surprised that you're the first person to point this out. That's the first thing I thought of when I read this:
No, it won't be some bratty Y Combinator startup. It'll be Google (but the Facebook/Twitter integration features won't be there, mainly because they're silly).
Even when GWT matures into the world-dominating SDK Joel speaks of, I still won't use it. To paraphrase jwz: Some people, when confronted with a problem, think, "I know, I'll use Java." Now they have two problems.
Then you would want to wrap the other GWT classes. Mainly what you would be interested in is the RPC libraries so you can directly send Java data types over the wire to the server using GWTs serialization/deserialization routines. You dont know how nice it is to not have to deal with complex XML parsing until you've actually experienced it. Its heaven on earth compared to manual Ajax programming.
Oh and the debugging... I shouldn't even have to explain the merit of this to an experienced Ajax developer.
Using Rhino for this seems kinda pointless though when you could just write it directly in Java. I find it ridiculous how some hackers have such an aversion to coding Java. I think if people took the time to learn GWT they would quickly discover what kind of competitive advantage it brings when building complex web applications (web applications, not simply web pages). Yes, it is verbose, but once you get the hang of it its very intuitive.
Why cant it be some Y Combinator startup who builds what Joel describes? GWT in the hands of a small team can build web applications that compete with Googles. If you dont believe me, then I challenge you to give it a try and see for yourself. Just dont give up too quickly; the learning curve is a bit steep.
I haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.
I also worked on SproutIt's Mailroom app, which is about 80% of the functionality of GMail, implemented by 2 dudes (one backend, one part-time front-end) over the course of a year (also in Ruby on Rails). Sprout's since released their toolkit, called SproutCore, but its docs are still a bit sketchy.
My $.02 -- too much of the plumbing for web 2.0 takes place on the server, which is why time to market on the server-side has been so important over the past few years. With Prototype, MooTools, YUI, etc. a lot of the fancy front-end tools can be bolted on after the fact.
Also -- how many apps fit the mold of a 100% full-screen AJAX app? Email, spreadsheet, word processing, calendar... what else? Reading news, surfing blogs (outside of an RSS reader), googling for information, etc. do not fit the mold of a 100% AJAX app.
You will definitely be very slow in building stuff initially, if you have not used GWT before. Much slower than using RoR. Unless maybe you've done lots of SWT/Swing programming, then you will at least have a general understanding on how to layout stuff graphically and use event listeners.
Everything in GWT is treated as AJAX app, in that all RPC's are asynchronous. But all GWT apps dont have to be "100% full screen". You have the freedom to do whatever you want visually, including wrapping JS libraries for animation, drag drop, etc (which I've done with my current project).
That being said, I agree with your comment about not everything fits the mold of an Ajax app. Like if you are not building a web application. Rails will be faster and more immediately gratifying in most situations.
>I haven't taken a look at GWT but I know of at least one ex-Googler that was trying to do a startup in Java/GWT and was hitting some major roadblocks/slowness of dev speed; they've since switched to RoR.
That is a bit odd, its a bit like saying you couldn't get Dojo to scale so you switched to Postgres. I assume if their startup was happy with ajax idioms in RoR, then they would be mad to build it in anything else, as it does so much for you (but if you stray too far, ouch).
I've had the same curiosity. The GWT compiler essentially parses the Java source code and uses a series of complex rules to convert it to JS. This is why whenever you use any client side libraries you must have the source code itself rather than just the binaries. If the source code cannot be parsed directly, it cannot be converted to JS.
In order for GWT to work for other languages it would need to be totally rewritten, unfortunately. That is unless you could somehow write an adapter for the core GWT JRE emulation library (java.lang & java.util classes). But like you say if the language your adapting to the Java code is not statically typed, you will have a hell of a time b/c the compiler is based on the assumption that the language is still java and therefore static. Like you say, you might end up having to force the programmer to follow certain conventions. Like always naming certain datatypes a unique way, so your adapter could map it back to specific static Java datatypes. But then doing this kind of defeats the purpose of using a dynamically typed language anyway..
Yeah my thoughts. Although I don't know if it impossible - GWT does work of an AST - no reason why other languages couldn't drive it. Perhaps the contenders would be scala (static) and JavaFX markup stuff (which is also static, and designed for UI).
I know its unpopular, but for GUI stuff I prefer statically typed code. It is more verbose, but I find GUI stuff really hard to test (even with friendly tools) and having the compiler do some more work for me I find saves time on silly errors when manually trying stuff out. Yes I type more (or my IDE does really), and I am doing the work for the compiler to some sense, but I find it easier then any other way I have worked for many years doing this.
Its actually ironic (in the alanis sense), I would love a good static typed GUI language, but a dynamic one on the server ;) Maybe my brain is backwards, but I haven't been convinced so far by anyone who has shown me they actually do anything with what they talk about.
I haven't written any Java code, but I recognize that my opinion was not formed by modern experiences: I was woefully unimpressed with the insanely slow craplets of the late '90s (and Paul Graham's mentions of Java in his essays didn't help improve my opinion of it either ;).