There was talk of getting rid of GWT a while back. I think it is useful for Java guys to prototype in, but it seems a bit of a monstrosity to me. There is frameworks like sproutcore, and you can hand roll with coffescript.
________________________________ From: Perry Smith <[email protected]> To: [email protected] Sent: Sun, 29 May, 2011 21:28:05 Subject: Re: protocols On May 29, 2011, at 3:10 PM, Thomas Wrobel wrote: >> >> If the majority of the client side is going to actually use javascript, then >>lets use that on the client side. >> >> I wonder... can Rhino[1] hook in to another Java application? Then we could >>use javascript on both sides and still test. > > Well, WiaB uses GWT for its webclient - so code wise its actualy Java > both sides, but then compiled to javascript. Yea. I thought about that but pulled back. I looked at GWT. I don't know if we say "foo" in GWT and that compiles to Javascript if that is really going to be "precisely" defined. GWT seems like it was moving rather fast six months ago so the translation of "foo" today may be a lot different than the translation of "foo" a year from now. GWT represents what I don't like about Java. It isn't really using Java directly but using things defined in Java. Each of those things would need to be defined. I've gotten the impression, perhaps mistakenly, that the average Java code could not get back to pure Java code without a tremendous amount of work. Now, it might be that since a protocol is rather simple, that the range of constructs used would be small. But, ultimately, any predefined construct (like an existing Java class or interface) would have to be defined in terms that could be verified.
