AFAIK the GWT choice was made cause it allows to code once the OT module - the same code works on the server and the client and no need to synchronize the changes. Another advantage of GWT is the ability to render the waves on the server side re-using the rendering code of the client side. Again - write once but use twice on both server and client.
2011/5/30 Paul Thomas <[email protected]> > 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. >
