> > Yes, the GWT/J2CL Google dev team is a bit behind, or maybe everyone > (including GWT team at Google) were a bit too optimistic. But I am 100% > sure J2CL will be released and open-sourced soon. And from descriptions > about J2CL we have seen so far, it does sound like the right minimal > approach. > Well, I am not entirely optimistic. I do agree that J2CL is the right minimal approach, I just don't agree that it should do away with things - it should at least have sufficient hooks to make compatibility possible (as it won't be there "out of box").
> Having said that my prediction is that GWT 3.0 plans will be quickly > abandoned once the community gets its teeth into J2CL. > Unfortunately, I have the same thoughts. One last point: I, many other GWTers and Google don't care about UI > binders, RPC, bundled Jetty servers and other failed ideas (GWT RPC=Java > RMI=cute, but bad idea long term) and will be unhappy if such legacy > baggage gets tucked into future releases of a J2CL-based product. That > leaves the fraction in the GWT community that has vested interest in the > legacy stuff to figure out way forward. > > That is a loaded statement and it is NOT the correct perspective of thinking for anything. For any large solution there will be many who don't care about parts of it. Sure, I do not personally care about UI binder, but others may have found it useful. We abandoned bundled Jetty a long time ago. Now, you say "and other failed ideas". The idea is NOT "failed" if you or someone else thinks so or hasn't found good use for it. If you take that approach then *everything* is a failure. People have moved off GWT because they no longer need Java (because JavaScript/TypeScript and other approaches). Both classic and super dev modes are failures. Code splitting is a failure because it can't deal properly with leftovers. Java-to-JavaScript translation is a failure because it is not debuggable or as fast as just coding straight in JavaScript. GWT Java emulation is a failure because it could not be complete. We can go on and on about that. Things are failures if they don't achieve their original goals and people don't find good uses for them, not if *someone* in isolation thinks they are failures. Furthermore, they are failures if they are given up on. Java-to-JavaScript isn't a failure because there is so much need for it. The same is true for GWT RPC. You are just plain wrong to say that it is Java RMI. It did take up some things from it but it is nothing like it and serves a very different purpose in very different ways. Furthermore, GWT RPC is not what the problem is here - if someone needs it, it could be reimplemented - but only if another part, the serialization part of it, is possible. And that is not legacy baggage. The need for this very much exists. Some people are happy with other frameworks that do the *same thing* but can't handle some cases such as non-public fields. Wther it is RestyGWT or anything similar it is all about communicating between the client and the server. Some like readable JSON and original GWT RPC did not do it (it did unreadable JSON :)). But otherwise they are exactly the same. The communication data format was not something that needed to matter in GTW RPC but it could have been made to be readable JSON. It could have been made even to use JSInterop and map classes to JSON to a point. To me personally that does not matter. I don't care whether is is JSON, XML, binary or ThingamaWatchaCallit. Show me ONE other framework that I can give to it a *cyclic graph* of objects to be sent over such that it requires no additional code to be written and that will let me include objects of unspecified third party libraries and I will move to it *NOW*. The problem is that you *won't find it* (I really hope I am wrong here, but I know that I am not). Are these other things better because they use, say JSON? Fine with me. Are they better because you can annotate some special behaviour? They are not - that could have been done differently with GWT RPC only in a different way. Are they better because they *can't do things*? No, quite the opposite. Think they are better beause they "force you to think" as someone has mentioned? I don't understand how anyone didn't think about what they are communicating, whatever they are using. Maybe they got burned by not thinking of it first, then had the opportunity to rectify that when they switched away and blamed GWT RPC for it. Still think you are right? See if developers of RestyGWT or other such frameworks don't desire some ways of accomplishing the functionality and ease of GWT RPC *serialization*. You may be surprised. Now, GWT RPC also has the other, ugly side, which is how services and methods are exposed. That was only good for minimal size services. We realized that early on and only tunneled through a small number of service methods to get the benefit of serialization. Give us serialization and we can use any other approach as well. And again, I for one, am not calling for GWT RPC to be resurrected in 3.0. I don't need it. But I do need the complete serialization instead of the half-baked, mostly-incapable external frameworks needing-a-ton-of-extra-code-and-still-can't-do-it in existence today. And I can even code that to work much faster than GWT RPC did (I do stuff like that all the time) but it isn't possible without dedicated hooks within J2CL. Be aware of others too. Please don't take the perspective of "I didn't need it so far so I am glad it is disappearing as nobody else will ever since I am making all there is and will be." -- 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/49b9bdb9-e417-4832-a349-7862703ed463%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
