With all this discussion on language/library, I'll definately stick to my choice of psuedocode so as to cut through any "controversy".
As for working on the waveprotocols site, what do I need to do to edit it. My Google account is the same as eMail except @gmail.com. Just don't contact me on it, I rarely look at it. -- Adrian Cochrane [email protected] On Mon, 30 May 2011 00:44 +0200, "Thomas Wrobel" <[email protected]> wrote: > 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. > -- http://www.fastmail.fm - IMAP accessible web-mail
