You are putting words in my mouth. Try reading my comment again. All I said was the approach we took was a lot faster and resulted in smaller code size, both of which are true. I said it came with some compromise, which for our use case and I suspect many others isn't a big deal. However, it also comes with other benefits. For example, we can easily communicate with non-java backends and services using the same JSON based approach.
It sounds like your use case isn't applicable to this approach. Google have made it pretty clear they don't want to use or support GWT RPC anymore. To be honest they are totally in their right to do this. This is one of the most one sided open source projects I have seen. Virtually all the work has been done by google over the years. Over the last few years all I have seen is people complain that their use cases (RPC, UiBinder, etc) are being abandoned. Now is the time to step up as a community and actually start contributing back. Our company relies on base widgets, UiBinder and Resources. If google doesn't offer these going forward, we will help to come up with alternatives that will work with J2CL. I would suggest you gather up support from everyone who still wants RPC and start planning to build an alternative. It sounds like you have lots of ideas how to make a better version. Talk is cheap, why not make something happen. On Sunday, May 21, 2017 at 9:03:55 AM UTC-4, Learner Evermore wrote: > > > > On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote: >> >> I am really interested to hear how you can make a version of GWT RPC as >> fast as a pure JSON approach. We take a tree of thousands of objects and >> just use one JSON.parse / JSON.stringify call to deserialize / serialize >> which happens within the browser in C++ code. No other processing is >> required. We use Overlay types to access the data and that is it. In the >> future we will switch to JsInteop types instead of overlays, that way we >> only have one version of our DTO's that are used on the client / server. >> > > As I suspected, you are comparing apples to oranges... > > > 1. You made dumb DTOs for this which means that you have to have the > code that copies data into them specifically for this purpose. And while > DTOs have followers for some cases they are *downright antipatterns* in > other cases. But we don't need to discuss that. > 2. You either don't have/use polymorphism or have had to code around > that as well. > 3. Any logic you have has to be either outside of the overlay types or > not polymorphic and you need to deal with that too. > 4. You also probably excluded the cost of delayed type conversion. > 5. How are you communicating long/Long? There are other examples. > 6. You can't include data of a third party library unless you have the > means to make full copies of it and keep in sync with that. > 7. Enjoy communicating cyclic graphs? > > > Then we come to the point of how much work you spend addressing the above, > esp. for complex types. We don't have to spend any of that. None. Zilch. > Nada. We have spent that time ensuring that we *never* have to send so > many objects even if we have to show millions (literally) and made our > product better overall. > > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/81724bf2-552d-4461-9f92-b6fc388f4840%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
