@Colin, I noticed your comments about RPC in another thread re this, not really related to what the thread is about either ("GWT csrf protection EXPERIMENTAL methods"). Can you share more details about capabilities, approach, timeline and licensing? I'd really like to know my alternatives as soon as possible and any impact. I am not concerned about GWT.create at all as we completely wrap+abstract that, but I am concerned about other things. Specifically:

1. Needs to be able to serialize private fields with no annotations, getters, setters or constructors that set them. No source or binary code changes must be required.

2. Effect on compilation time, participation in (Super) Dev Mode, etc.

3. Ability to run this at product deployment/installation time (post-development, we run GWT compiler to "link" the base product with the plugins made by other parties). Also what does it take to have our (independent) plugin developers use it?

4. Open source? If not, what assurances we'd get this does not end up like Sencha GXT (another headache I have)?

Re compilation - yes, I agree that "many" have given up on it and I am aware of those listed. But the huge majority did not. The whole reason JavaScript and pure JavaScript frameworks are so popular in its raw form is that it requires no development tools at all to get started. Every Joe and Jane can get started and accomplish something. This is also the proof that "most popular" has nothing to do with the "best" by any stretch of imagination.

TeaVM does come up with larger code but I wouldn't say double. Furthermore, this is about the optimization stage. TeaVM brings its own (albeit simple) garbage collector to WebAssembly making it possible to start... and shift to the WebAssembly one when it appears. Finally, if the optimizer planned for GWT 3 is really just a JavaScript optimizer, then it can be applied to TeaVM as well...

Re RPC I am *VERY* interested. I was digging through this myself but have come up with two approaches. One requires interfacing with the compiler. This is a better/faster approach. The other requires massive source pre-processing to inject synthetic methods into the input for the GWT compiler. This is needed even for standard library classes as they too can (and should) have private serializable fields.

GWT 2 isn't dead. We are at 2.8.0 right now, about to take on 2.8.2 and check it out. The problem is that GWT 3 is advertised in a way that spells a dead end for GWT 2 code.

Sencha GXT is a big problem for us. Licensing is a big issue. It is a zombie now.  Neither alive and OK to be promoted further nor dead so that we can claim the corpse and do stuff with it. 

Bytecode to closure is possible. If you have the source code you can use it, but this isn't absolutely required. With respect to "another Sencha" happening we're in between a rock and a hard place now. (1) We depend on Sencha. (2) In order to support 3rd party deployment-time plugins we have to ship with our source code and we also require those 3rd party devs to do the same. We obfuscate this code to a point but we can't really do much to it. I know this is almost pointless as one can decompile Java, APIs are hard to obfuscate and, if we were to write in JavaScript it would have been all source code anyway, but it is a sensitive topic for companies that follow the traditional non-open source model.

I just saw this thread... I have voiced similar concerns in other places.

Just as a language, Java is way better for large development than JavaScript can ever be, for reasons we don't need to discuss here. However, this is not enough to make GWT or any other framework successful in the browser world.

1. Java is not something that other developers make things for to run in the browser, so we rely on interop. Interop isn't needed if you are writing in JavaScript.
2. Java requires compilation. JavaScript does not. This is a step that many new developers aren't accustomed to and see as a nuisance, however short or long it takes.
3. Debugging Java code in browser was never solved fully. Classic dev mode was painfully slow, "Super Dev Mode" is painful to inspect. Yes, you see the code but you can't see the data correctly.

To us and, I suspect, to many others, the GWT was a hit because it answered the following:

1. Java syntax/language offers control and discipline and a way to avoid pitfalls of JavaScript. This only fully works, however, if you only stay in Java world. The more you interface with JavaScript the less of this you have. Furthermore, I don't need GWT for this. I might as well use just J2CL or any other available approach, such as TeaVM (heck, that even runs faster than GWT/J2CL as it can compile to WebAssembly).
   
2. Code sharing so that we do not have to write the same code separately for the client and for the server. No, atrocity called 'node.js' does not count. That is a separate discussion anyway. Yes, GWT 3 can check this box between the client and the server of the same thing but does significantly less than GWT 2 does. Sharing composite widgets? Forget about it. Sharing code that communicates data? Forget about it. There is no framework that can replace GWT RPC to the level needed. If you are creating a large product, you will end up using different code from different people. If those don't agree on RPC-replacement frameworks to use you're in trouble. Any data you may want to communicate has to be exposed even when you don't want to... goodbye private data. Goodbye safe API development.
   
3.  Ability to encapsulate screen content into reusable and composable widgets. Widgets may not be popular in HTML/DOM world but they are, without a doubt, the most reusable and maintainable approach for building UIs that also abstracts the underlying technology. If I wanted to work directly on HTML DOM and use JavaScript frameworks, then I would use what these are made for and will support until their own death... and that is NOT GWT/Java. But GWT 3 gets rid of widgets. The desire is to use what JavaScript guys are using. That's not better, that is a defeat and death. I don't need GWT/Java for that.
   
4. GWT offered a way for the client (browser) and server code to work together seamlessly. This was and still is clumsy, lousy and painfully slow to compile - the GWT RPC. But it made things possible and took a huge chunk of boilerplate development away that nothing in GWT 3 can do (I mean it). We have put a lipstick on the pig that is GWT RPC and it is a pleasure to use (you don't see it anywhere, you don't even need to do GWT.create, you just call the server method you want, it feels almost as if the server code is *in* the client). We only suffer the compilation time due to it but there are ways to solve this. GWT 3 approach? Don't fix/improve, remove. Use other frameworks, reconcile multiple of them when you are forced to, create a lot more boilerplate code.

Like some other companies, we built products around GWT. We exposed our APIs and encouraged others to build extensions, plugins. We bring/link those together at deployment time. Our product is huge and complex due to the nature of what it has to do.Sharing code is important. We allowed our plugin developers to share their code between the browser, UI server and even other components of the system. To optimize performance we often have to communicate objects from multiple plugins bundlled together, through common calls/requests. We implemented server pushes. We implemented the entire UI as widgets to which they can add their own. The API is well documented (JavaDoc) and clean/safe - not everything is public/protected. We intentionally change and improve our widgets and that does not affect anyone in a bad way, whether their widgets contain ours or the other way around. All this was done with GWT widgets and GWT RPC.

The voices of those who do not need features, like Widgets and, especially, RPC seem to be louder than those of people who do. They are calling for diluting of GWT and making it more like anything else. When you do that, however, you lose differentiation and your benefits too.

We are now in a pretty desperate position. The company does not see any spark of hope to steer GWT 3 back where it should be going, so we're not even attempting anything. Hence the anonymous postings from me. Yet we have a huge code base and 3rd party plugins to work with. It really should be simple:

a) Remain compatible with widgets. Many will be grateful. Make them optional and, perhaps a separate project if you wish, but have them. BTW, we also use Sencha GXT. Care to guess what is going on with that?

b) OK, get rid of GWT RPC. It can be done much better than it has been done anyway. But allow a J2CL extension point that can be used to implement all the functionality that RPC was able to do, including communication of unannotated classes with private fields. For example, the plugin could leverage the code representation objects and generate synthetic accessor methods not visible to anyone else. 

That's all that's really needed, if not too late. There's other stuff that can be done such as not requiring the source code, operate on byte code. JBytecode2CL if you wish. Don't require source code. Sure, existing code generators would still have to work via source but that isn't impossible to address. What does this do? It opens doors to many more libraries, makes them easier to use, can use languages other than Java that compile to Java bytecode and allows library or plugin developers to not have to ship their source code. 

Super disappointed,

Learner