Thanks so much for replying! I read that JavaScriptObjects are an opaque handle in the javadoc http://google-web-toolkit.googlecode.com/svn/javadoc/1.6/com/google/gwt/core/client/JavaScriptObject.html
When you mentioned how server side performance is different, is it because of the protocol used to marshall and unmarshall the data once it arrives on the server? You mentioned that the DOM is much more of an issue? In what sense? And how does one go about optimizing for this? I always believed that gwt's deserialization via gwtrpc back into the client side was the bottleneck. Which is why I began to consider other options such as JavaScript Overlay Types. But then again, I guess forgot that I would have to manage the JSON (or turn them into POJOs, the advantage of GWTRPC you were speaking of I assume?) on the server as well. I suppose the plus side to this is that there is very little deserialization that is needed to be done on the client side. Would I be correct in saying that, since I can't change the speed of my client's computer, I should place the deserialization/serialization work on the server (which I could always allocate more resources for? I guess really I'm looking for bottlenecks or an architecture that would give great scalability~ On Mar 14, 3:43 pm, Thomas Broyer <t.bro...@gmail.com> wrote: > On Wednesday, March 14, 2012 4:35:27 PM UTC+1, Elizabeth Lemon wrote: > > Hello everyone, > > I have been looking around for a really long time now on these client- > > server communication strategies and have had a difficult time choosing > > the right approach for my application. It also doesn't help that I > > don't have a very strong background on server sided coding :P > > > In any case, I am trying to find the approach that would give the best > > performance on the client-side. > > > I know that GWT-RPC uses it's own protocol to get you to the server > > side. It is built on top of RequestBuilder and converts your data > > into a content-type of (what I read was) text/plain. From here, it > > will reconstruct your java object onto the servlet. > > > JavaScript Overlays says that it has no overhead. > > > RequestFactory is supposed to be even faster than GWT-RPC. No > > serialization is required, but apparently deserialization is. > > > Upon these, there is the old RequestBuilder with a JSONParser. > > > I want to minimize the amount of time it takes for the client to > > deserialize it's data with a balance of data size. > > > My objects aren't too deep. At most, an object would contain a couple > > of strings, and two arraylists of 100 objects than contain a couple of > > other strings. > > > But if I can avoid the deserialization part (where I believe most of > > the response time is being consumed by) by a simple eval on a JSON or > > something, that would be great. > > > Other notes: I have flexibility in what server I can use. However, > > eventually I would like to make web services for non-gwt platforms, > > though I feel like I could reuse the same business logic and use a > > different entry point to the service. > > QUESTIONS: > > 1. What does it mean for JavaScript Overlays to have no overhead? > > JSOs are a way of coding in Java against JavaScript objects. The JSO class is > a shim that get totally compiled out: no overhead, no wrapping of the JS > object. > > > 2. Which one would you say is fastest in terms of client side > > performance? > > Most probably JSOs, with JsonUtils for parsing. > Next I'd say AutoBeans, then RF, then RPC. > Note that server side performance is different: the rpc protocol is much > simpler than RF, so it's faster. > > > 3. What does it mean that JavaScriptObjects are Opaque? > > Where did you read that?! > > > 4. Since JavaScript Overlays describe us extending JavaScriptObjects, > > does that mean converting it to a JSON requires less (or even zero) > > time than would GWT-RPC? > > Yes. > Most browsers can do JSON.stringify(), for others you'd have to use > JSONObject.toString(), which has a small overhead. > > > > > Thank you so much for your input~ > > Choose what works best for you (in terms of protocol), not necessarily the > fastest. These won't be the bottleneck of your app's performance, DOM is much > more of an issue (and of course the network and the server) > > > > > > > > On Wednesday, March 14, 2012 4:35:27 PM UTC+1, Elizabeth Lemon wrote: > > Hello everyone, > > I have been looking around for a really long time now on these client- > > server communication strategies and have had a difficult time choosing > > the right approach for my application. It also doesn't help that I > > don't have a very strong background on server sided coding :P > > > In any case, I am trying to find the approach that would give the best > > performance on the client-side. > > > I know that GWT-RPC uses it's own protocol to get you to the server > > side. It is built on top of RequestBuilder and converts your data > > into a content-type of (what I read was) text/plain. From here, it > > will reconstruct your java object onto the servlet. > > > JavaScript Overlays says that it has no overhead. > > > RequestFactory is supposed to be even faster than GWT-RPC. No > > serialization is required, but apparently deserialization is. > > > Upon these, there is the old RequestBuilder with a JSONParser. > > > I want to minimize the amount of time it takes for the client to > > deserialize it's data with a balance of data size. > > > My objects aren't too deep. At most, an object would contain a couple > > of strings, and two arraylists of 100 objects than contain a couple of > > other strings. > > > But if I can avoid the deserialization part (where I believe most of > > the response time is being consumed by) by a simple eval on a JSON or > > something, that would be great. > > > Other notes: I have flexibility in what server I can use. However, > > eventually I would like to make web services for non-gwt platforms, > > though I feel like I could reuse the same business logic and use a > > different entry point to the service. > > QUESTIONS: > > 1. What does it mean for JavaScript Overlays to have no overhead? > > 2. Which one would you say is fastest in terms of client side > > performance? > > 3. What does it mean that JavaScriptObjects are Opaque? > > 4. Since JavaScript Overlays describe us extending JavaScriptObjects, > > does that mean converting it to a JSON requires less (or even zero) > > time than would GWT-RPC? > > > Thank you so much for your input~ -- You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
