> > As a heavy user of GWT-RPC in a large app, I've become disillusioned with > it. That's for three reasons: > > GWT RPC has its deficiencies. I don't have much to add to https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ However, the serialization alone (used within GWT RPC) is its own beast with its own deficiencies and benefits. One deficiency I can mention is that it isn't completely compatible with java.io.Serializable contract. Customization is done via separate _CustomFieldSerializers. I understand why it had to be done that way, to handle some special cases but ultimately standard approach was also possible with little loss of efficiency, if any - just using a different underlying stream implementation.
> - I often need to see what data is being sent, and it's just not very good > for that. It makes debugging harder than it could be. > Well, actually, you don't need to see it if it works.You need to see what is sent and received. Second, "seeing" it is not that hard. There are solutions to it and we have our own (very rarely needed). - it's not good for communicating from a mobile app. > > That does not depend on whether the app is mobile but whether it has a matching (de)serializer. If your app is web-based GWT app you can use it, it works no worse (in fact better) than other approaches. If it isn't, then I agree, GWT RPC isn't for you. Never was. That isn't its purpose. > - it's much too easy to accidentally send much more data than necessary. > Being forced to think about your content on-the-wire would probably make a > better product in the long run. > > There is *no difference* in thinking you need to do between those. We did put thought of it and we're perfectly fine and didn't have to write as much of ugly glue code and duplicate code to use other frameworks. Being forced to think about anything is good in some cases but not others and does NOT generally make a better product in any run length. Examples: a) If you think about hardware efficiency you should program in assembly, shouldn't you? b) Never use databases, they are an abstraction of the file system. Use files directly, make them best for your need. Better yet, talk to underlying storage hardware. c) Always implement your own security checks all over the place. You''ll be sure that it always does exactly what it needs to. Problem is that this is what happens if you follow logic like that: 1. Your immediate logic seems to operate faster at the low level. 2. You have spent time on low level and not on your business, hence your high level is less optimized. 3. You're ignoring the big picture. Yes, it may indeed be faster to take one person from point A to point B in a race car but most of the time we actually want to take dozens. A "slow" bus wins here by a lot. So we're going to pay the price to migrate away from GWT-RPC and I don't > feel too bad about it going away. > > You can, are willing to do so, and don't care about others because of your personal needs. I don't ignore the needs of those who use things I don't. I may be lucky in some cases but it is a wrong thing to say "I don't have a need for it thus nobody should". Furthermore, you can say that you can migrate. We can't. If we migrate our code that still leaves the code of those that are built on top of our solution. It leaves the joint customer stranded too. Finally, if there isn't ONE framework that rules them all you have the trouble of combining libraries. Library A uses framework P, library B users framework Q, you need to communicate their data (at least) through your framework R and P != Q != R. > I just hope we don't have to give up widgets too. I don't see that being > practical for us. > > For us neither abandoning widgets nor RPC is "practical" (possible). How would you feel if someone said "We only used GWT to drive Angular, didn't use widgets at all, don't feel too bad about them going away"? -- 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/06ff19f1-7c34-442c-b4c7-a100f17a79f7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
