4 ms·
Yeah I am trying to find out. They are here at javaone - doing too much UI on the server side does seem like a real mistake for a tool like this. One of the nic
by michaelneale 17y ago
Yeah I am trying to find out. They are here at javaone - doing too much UI on the server side does seem like a real mistake for a tool like this. One of the nice things of things like this (and cappaccino) is that the server side becomes freed from worrying about what the client is doing/has open etc...
- jojule 17y agoThis is a matter of taste - benefits of the server-driven architecture are: no limits from the server, no GWT recompilation, direct access to server-side API and resources, better security, full Java virtual machine, full tooling and debugging support. Downsides are: more client-server traffic, more data to store in HttpSession.
- DenisM 17y agoI think the most impmortnat problem is trying to hide the netowrk under an inhenrelty leaky abstraction: http://www.erlang.org/pipermail/erlang-questions/2008-May/035207.html http://www.erlang.org/pipermail/erlang-questions/2008-May/03...
- michaelneale 17y agoyes that is what worries me - I like network stuff to be explicit.
- jojule 17y agoThere are multiple levels of control: 1) for each UI component you can select to send events immediately to server or alongside the next "packet" sent to server. 2) as we are building on top of GWT - you have the full GWT-based RPC also if you want to do the communication manually.