As a gwt coder, that seems rather reinventing the wheel for no good reason. :) What gwt does for you is abstract away almost all browser differences leaving a very pure coding expirence to make webapps. "foo" most certainly isnt always the same when compiled because different browsers have both different javascript as well as layout engines. GWT gives you a generic "foo" for you to code in and compiles to different implementations per browser to give the end result as close to identical as possible, while ensuring no browser has to waste loading time on quirks for other browsers.(at the same time being very heavy at optimisation). So, by design, foo is not always a fixed thing. For what it does, gwt does very well, you'd be hard pressed to come up with a better replacement without a lot more manual work.
In regards to widgets,layouts, and general web interface gwt is always going to unpredictable and changing at the html level. However, in regards to pure coding, its pretty stable. It could basicly just be seen as a subset of java. Specificaly this subset; http://code.google.com/webtoolkit/doc/1.6/RefJreEmulation.html (The biggest thing I've come accross personaly is just having to rememeber its Javascript style regexs) So porting to gwt is a problem if you use more then those, but porting away is never any work as its "just java". (I often reuse logic code between my gwt apps and my android stuff - as long as your not dealing with visual stuff theres rarely any issues) That said, I'm not saying its a great for a referance implementation, merely a way for all the code both sides to be done in Java if thats an advantage. At the end of the day I asume we are (probably) looking at a websocket based system anyway - possible sending messages done using an existing websocket implementation? So the question is over the code forming and packing what to send, as well as the code picking up the responses. The layout code doesnt play any role in this really. Its also quite possible to have a Javascript lib that a gwt app can interact with. (Or native javascript statements in gwt). Theres no reason why not to play to the strengths of various platforms. So you could have Java (Wiab server) >>>>(websocket)>>>>CS protocol Javascript lib>>>(generated javascript fropm gwt or something else) On 29 May 2011 23:12, Paul Thomas <[email protected]> wrote: > 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.
