Business proposition of GWT 3.0 - what is it good for vs. other solutions out there?

[Learner Evermore]

Hi there!

I am faced with having to re-think what we are doing in the company I work for with respect to GWT, existing and new projects and I am struggling, to say the least. We've been very much a GWT shop for years now and have used it to expedite the development of very large solutions and improve the end user experience. We did this and this was possible because:

1. There is (was?) a visible big name behind the technology - Google. There were regular updates and a lively community. 
   
   
2. It allowed us to share a lot of code between the client and the server properly and use a programming language suitable for very large software - strong typing, encapsulation/visibility control and all the works. JavaScript just isn't an option - it isn;t even a thought with all the enhancements they are making.
   
   
3. It allowed us to cleanly and efficiently segregate and encapsulate functional responsibilities of both business and representation code. We were able to create a foundation with clean APIs that other teams build their modules on top - and we bring those modules together. We can evolve that foundation and dramatically change it looks beyond just CSS because we encapsulated units of UI into widgets and we came up with the means to aggregate client-server communication from all modules into single requests/responses via serialization (we otherwise used GWT RPC very little - there is a single service with a single method in there).
   
   
4. It offered integrated code optimization and debugging tools with what seemed to be a promising future vision and dedication.
   
   

We've been following what is going on with GWT 3.0 and, admittedly, didn't like it. However, we were hoping that our problems are common and that it will become apparent that GWT 3.0 vision needs some adjustments. We've observed other people communicating similar perspectives to ours. Unfortunately, we've also seen little acceptance of these comments, little action and, essentially, no direction with respect to those beyond "waiting to see what happens with GWT 3.0". We believe that this effective limbo is, at least, a big part of the reason for frequent statements like "GWT is dead, past its time" and abandoning the technology simple because they have to move forward but are left behind.

I/we perfectly understand the reasons why one would want to do things planned for GWT 3.0. Removals of GWT RPC and widgets can simplify some code and increase the performance of the tools, among other things. At the same time, I believe that the perspective taken to decide what to do is wrong. Instead of finding ways to simplify GWT at the expense of making GWT-based products more complex and loosing any chance of being compatible with pre-3.0 code, efforts should have been focused on solving the problems. I know that these problems are hard, but they are also possible to solve. I know because I made solutions to similar problems. Yes, new GWT may produce code faster and it may produce faster code and it may interoperate better with the browser and JavaScript. But consider the following:

1. For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
   
   
2. For sharing code with the server, some people use node.js (I do not subscribe to this) but there are other options - JSweet, TeaVM, possibly Dragome and others.
   
   
3. For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly.
   
   
4. If one is forced to use external frameworks for serialization they don't get any benefits from GWT that other alternatives don't also get.
   
   
5. In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries...
   
   
6. If we're to work directly with the metal, similar to how JavaScript frameworks do things, then again - JSweet may be a better fit, possibly TeaVM. Neither has widgets in a sense GWT does/did.
   
   

Put it simply, GWT 3.0 does not seem offer a path for existing users, does not have much novel for brand new users that isn't already available othewise and better, takes more time to do whatever it does and slows down the development and is losing trustworthiness - what guarantees that, if I start with GWT 3, I won't be left stranded when GWT 4 comes out... if it ever will?  So, who is GWT 3.0 for? Who will use it?

Does this mean that there really is no vision about how GWT can truly evolve and grow? If so, let me offer some of my challenges that would be best solved or need to be solved in GWT, in no particular order.

1. Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work.
   
   
   
2. Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package.
   
   
3. Separate widgets into an optional module but definitely keep them going. They are important. They are used, both directly and via 3rd party libraries.
   
   
4. If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
   
   
   
5. Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules.
   
   
6. Deferred binding and code generators are something we do not use directly as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too.
   
   
7. JSNI methods in comments were nice but are the only thing that truly requires the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni
   
   
8. Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective).  We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new.
   
   
9. Clean up the tooling. Stop embedding everything in a single monolithic jar, update code coverage tool support. Rethink debugging - perhaps leverage existing work done outside GWT for this? Separate the classpath of the compiler from what it is supposed to compile. These are not the same thing and cause grief.
   
   

Without the above, what seems to be a closer alternative to existing GWT 2.x users is a separate fork of GWT (that may not be coming any time soon) or a TeaVM enriched with a fork of GWT widgets and a module doing GWT RPC (possible!). It does not have code splitting support (yet) and, likely, no desire (or need) for "permutations" and related concepts. That would require widget libraries to be rewritten with that in mind, but that would be possible and would, it seems, yield a better dev environment with a better performing end result.

I don't want to see GWT fail. We have our future depending on it and, if we can't use it, I presently don't know what we can do. But we cannot use GWT 3.0. Remember - "I don't need it" is not the same as "Nobody needs it" and "shouldn't need it" is a matter of perspective typically uttered by those who don't create projects as complex as many of us others do. 

[Relja Pcela]

It would be really nice to see some new answers on this kind of questions from GWT contributors other than: "We don't know how GWT3 will look like in this moment but we know that J2CL will not include this and that" because this sentence is almost 2 years old.

[Ray Cromwell]

On Thu, May 18, 2017 at 9:29 AM Learner Evermore <learner....@gmail.com> wrote:

1. For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
   

Keep in mind that, last time I looked, JSweet is not really Java and can only compile a much smaller subset of Java, it does not fully obey JLS semantics.  i.e. can it compile Guava out of the box?

1. 
   
2. For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly.
   
   

IIRC WebAssembly doesn't do much for GC collected languages. You are not allowed to dynamically allocate heap objects, unless you implement your own memory management. I don't know if TeaVM does this, but it is typically only used for stuff like C++->JS transpiling. The TeaVM benchmark vs GWT does not disable GWT's internal preconditions checks, I'd be curious to see these re-run. Last time I looked, code size was larger for TeaVM, and for web, code size tends to dominate subjective performance except in rare cases like games or codecs.

1. 
   
2. In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries...
   

GWT is not a translator, it's a whole program optimizer, that's why it's slow. Google's next-gen J2CL compiler does transpilation to human readable ES6 Closure annotated code.  (https://qconnewyork.com/ny2016/ny2016/presentation/j2cl-future-gwt.html) This is being deployed on inbox.google.com right now. Much faster transpilation, since it operates like JSweet during development, but it produces fully JLS compliant code.

1. Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work.
   

1. 
   

There's a possibility this could be done, but I think the community will need to do it. I prototype Async/Await for GWT it a while ago (https://plus.google.com/+RayCromwell/posts/cDVuTGccK3p) using Babel, but these days, I'd use Closure Compiler's transformations. Nothing comes even close to Closure's optimization ability.

 

1. 
   
2. Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package.
   

Driving up the # of split points in GWT has pitfalls. GWT only creates on shared fragment (the leftovers fragment) which will grow larger and larger. It needs to create a tree of shared modules, like Closure Compiler works with, or Malte Ubl's splittable's project.

 

1. 
   
2. 
   
3. If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
   
   

GWT RPC is fundamentally a de-optimization. Java serialization is bad for the same reason that full reflection support is bad.  It's actually worse than that, because computing the minimal object graph for a given RPC call has been shown to be equivalent to solving the halting problem. What's wrong with the solutions people in the Android community are using? Like Square Retrofit and RxJava? Or JaxRS solutions like https://github.com/intendia-oss/autorest which also uses RxJava2? This code will work on multiple platforms and not just for web clients. ReactiveX makes building UIs with lots of asynchronous calls even better than async/await IMHO.

1. 
   
2. Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules.
   

J2CL is replacing this with incremental compilation, so they're not needed anymore. Roughly only about 15-20% of time is spend parsing Java IIRC, in large projects, compile time is dominated by the optimization passes.

 

1. 
   
2. Deferred binding and code generators are something we do not use directly as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too.
   

Annotation Processors are the legitimate, Java-idiomatic way to do this going forward.  It's Java standard, works in IDEs and with the ecosystem, and is cross platform (Web/Android/j2objc/JRE)

1. 
   
2. JSNI methods in comments were nice but are the only thing that truly requires the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni
   
   

JsInterop already provides this as does J2CL. There is almost no need for JSNI or JS fragments anymore with JsInterop and Elemental2 (https://www.youtube.com/watch?v=7QI4DSkJ5DQ)  JsInterop works optimally (doesn't bloat output compared to other solutions), and Elemental2 includes generators which can automatically read TypeScript header files or Closure Compiler externs and produce Java JsInterop from them.

 

2. Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective).  We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new.
   
   

With @JsType/@JsMethod you can export any shared interface between plugins. You can then separately compile the plugins. The downside is that you'll have multiple copies of the JRE loaded. There's not really an easy way to solve this problem because you don't know ahead of time what needs to be run-time linked, and what can be statically linked. 

For more options, visit https://groups.google.com/d/optout.

[Learner Evermore]

Keep in mind that, last time I looked, JSweet is not really Java and can only compile a much smaller subset of Java, it does not fully obey JLS semantics.  i.e. can it compile Guava out of the box?

Yes, I am absolutely aware of that. That point is restricted to just interoperability whilst using Java syntax. GWT seems to be reducing what it can do with Java, not increasing.

 

IIRC WebAssembly doesn't do much for GC collected languages. You are not allowed to dynamically allocate heap objects, unless you implement your own memory management. I don't know if TeaVM does this, but it is typically only used for stuff like C++->JS transpiling. The TeaVM benchmark vs GWT does not disable GWT's internal preconditions checks, I'd be curious to see these re-run. Last time I looked, code size was larger for TeaVM, and for web, code size tends to dominate subjective performance except in rare cases like games or codecs.

That is correct. TeaVM implemented GC in WebAssemblt for this purpose - it does its own memory management. Disabling GWT precondition checks may make it comparable to TeaVM (assuming it doesn't do this), not (significantly) better. TeaVM size is approximately equal between TeaVM and GWT.

GWT is not a translator, it's a whole program optimizer, that's why it's slow. Google's next-gen J2CL compiler does transpilation to human readable ES6 Closure annotated code.  (https://qconnewyork.com/ny2016/ny2016/presentation/j2cl-future-gwt.html) This is being deployed on inbox.google.com right now. Much faster transpilation, since it operates like JSweet during development, but it produces fully JLS compliant code.

TeaVM is also a whole program optimizer. It eliminates unused methods and performs inlining and minification, includes only needed code. Readable output may indeed be helpful but only in edge cases. Why should I care about readability of that if I develop in Java and want to debug in Java?

There's a possibility this could be done, but I think the community will need to do it. I prototype Async/Await for GWT it a while ago (https://plus.google.com/+RayCromwell/posts/cDVuTGccK3p) using Babel, but these days, I'd use Closure Compiler's transformations. Nothing comes even close to Closure's optimization ability.

Community can only do it if the foundation allows it.

  

Driving up the # of split points in GWT has pitfalls. GWT only creates on shared fragment (the leftovers fragment) which will grow larger and larger. It needs to create a tree of shared modules, like Closure Compiler works with, or Malte Ubl's splittable's project.

It the current, flawed (in my opinion) implementation. It does not need to do it this way. With simulation of synchronous execution even of asynchronous server requests for more code any call can become a split point. anywhere... and we can let the developer quite literally choose how to split code. A lot less analysis needed upfront, even though it may be useful as an informational tool to the developer.

 

GWT RPC is fundamentally a de-optimization. Java serialization is bad for the same reason that full reflection support is bad.  It's actually worse than that, because computing the minimal object graph for a given RPC call has been shown to be equivalent to solving the halting problem. What's wrong with the solutions people in the Android community are using? Like Square Retrofit and RxJava? Or JaxRS solutions like https://github.com/intendia-oss/autorest which also uses RxJava2? This code will work on multiple platforms and not just for web clients. ReactiveX makes building UIs with lots of asynchronous calls even better than async/await IMHO.

Neither Java serialization nor GWT RPC are "bad". They may be challenging to implement, not bad. There is nothing better than Java serialization when communicating objects of multiple third parties between the client and server. Only it has efficient access to private fields so it cannot even be implemented outside w/o writing a complete code-preprocessor to generate new source code with synthetic methods. Java reflection is good, just requires content we presently don't desire on the client. It is a challenge, not a bad thing. Read https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ

 

J2CL is replacing this with incremental compilation, so they're not needed anymore. Roughly only about 15-20% of time is spend parsing Java IIRC, in large projects, compile time is dominated by the optimization passes.

Incremental compilation is relevant only on a single dev machine. *.gwtar files can be distributed and optimize compilation elsewhere. They would be *very* much helpful to us.

 

JsInterop already provides this as does J2CL. There is almost no need for JSNI or JS fragments anymore with JsInterop and Elemental2 (https://www.youtube.com/watch?v=7QI4DSkJ5DQ)  JsInterop works optimally (doesn't bloat output compared to other solutions), and Elemental2 includes generators which can automatically read TypeScript header files or Closure Compiler externs and produce Java JsInterop from them.

No future need for future code maybe. Is there an automated migration path?

 

With @JsType/@JsMethod you can export any shared interface between plugins. You can then separately compile the plugins. The downside is that you'll have multiple copies of the JRE loaded. There's not really an easy way to solve this problem because you don't know ahead of time what needs to be run-time linked, and what can be statically linked. 

There are ways to do this, absolutely, one just needs to think outside the box. With a combination of *.gwtar, synchronous code loading and similar approaches what is presently a SuperDevMode servlet may become a ProductionBundleServlet, for example and still do its job quickly. We could have the means to link the bits together as needed - so not entirely run time, but close. Single "JRE" would absolutely be important for memory and performance reasons.

[Ray Cromwell]

On Thu, May 18, 2017 at 5:20 PM, Learner Evermore <learner....@gmail.com> wrote:

Yes, I am absolutely aware of that. That point is restricted to just interoperability whilst using Java syntax. GWT seems to be reducing what it can do with Java, not increasing.

I'm not sure I understand. If you use JSweet, it is very likely to break on using libraries from the Java ecosystem, which breaks a huge value proposition of using Java in the first place. It doesn't even support static field initialization and class initializers with proper semantics last time I checked. Someone who has learned Java will be very surprised at weird failures in the pipeline. GWT has parts of the JRE it doesn't support, but from a language level, it passes most of the JLS spec with some exceptions around numerics, overflow checks. My advice is, if you need a language with types and good IDE support that maps to JS, use TypeScript or Kotlin. Kotlin every has a great Java interop/JVM ecosystem story and amazing IDE support. 

 

 

IIRC WebAssembly doesn't do much for GC collected languages. You are not allowed to dynamically allocate heap objects, unless you implement your own memory management. I don't know if TeaVM does this, but it is typically only used for stuff like C++->JS transpiling. The TeaVM benchmark vs GWT does not disable GWT's internal preconditions checks, I'd be curious to see these re-run. Last time I looked, code size was larger for TeaVM, and for web, code size tends to dominate subjective performance except in rare cases like games or codecs.

That is correct. TeaVM implemented GC in WebAssemblt for this purpose - it does its own memory management. Disabling GWT precondition checks may make it comparable to TeaVM (assuming it doesn't do this), not (significantly) better. TeaVM size is approximately equal between TeaVM and GWT.

I just checked the demos on Github, TeaVM's box2d demo loads 306kb of JS (when uncompressed).  WebAssembly version is ~500kb uncompressed. The GWT version is 148kb uncompressed. The J2CL Box2D demo we use internally, while not strictly an apples-to-apples comparison, is 35kb uncompressed. 

TeaVM is also a whole program optimizer. It eliminates unused methods and performs inlining and minification, includes only needed code. Readable output may indeed be helpful but only in edge cases. Why should I care about readability of that if I develop in Java and want to debug in Java?

Yes, it's a whole program optimizer, but it's about 50% worse than GWT at pruning, and a lot worse than J2CL + Closure Compiler and it doesn't support code splitting.  Why should one care about readability? Because besides source maps, it makes it much more transparent what's going on AND it integrates with the rest of the ES6 module system very easily. Every Java file can become a ES6 module, and any JS file can simple require/import it as if it was any other hand-written JS. This makes it very easy for JS programmers to work with it (Inbox.google.com is 60% Java, 40% JS). It makes Java more of a natural, first class member of a JS ecosystem. If you like JSweet, this does the same thing, only much better.

 

There's a possibility this could be done, but I think the community will need to do it. I prototype Async/Await for GWT it a while ago (https://plus.google.com/+RayCromwell/posts/cDVuTGccK3p) using Babel, but these days, I'd use Closure Compiler's transformations. Nothing comes even close to Closure's optimization ability.

Community can only do it if the foundation allows it.

The foundation allows it, but it's hacky. I showed how it could be done.  You can use a Generator + Linker combo to get async/await annotations in the output, and then invoke BabelJS from the linker to transpile the ES7 async/await calls back into ES5.

 

  

Driving up the # of split points in GWT has pitfalls. GWT only creates on shared fragment (the leftovers fragment) which will grow larger and larger. It needs to create a tree of shared modules, like Closure Compiler works with, or Malte Ubl's splittable's project.

It the current, flawed (in my opinion) implementation. It does not need to do it this way. With simulation of synchronous execution even of asynchronous server requests for more code any call can become a split point. anywhere... and we can let the developer quite literally choose how to split code. A lot less analysis needed upfront, even though it may be useful as an informational tool to the developer.

Yes, any call can be come a split point, and we do that at Google on projects like photos.google.com, where every controller, every event handler, every widget, or every data request is a split point. But GWT doesn't support this, someone needs to significantly improve the CodeSplitter in GWT to make this worthwhile, otherwise, it will made total code size loaded in the first split point triggered worse.

 

 

With @JsType/@JsMethod you can export any shared interface between plugins. You can then separately compile the plugins. The downside is that you'll have multiple copies of the JRE loaded. There's not really an easy way to solve this problem because you don't know ahead of time what needs to be run-time linked, and what can be statically linked. 

There are ways to do this, absolutely, one just needs to think outside the box. With a combination of *.gwtar, synchronous code loading and similar approaches what is presently a SuperDevMode servlet may become a ProductionBundleServlet, for example and still do its job quickly. We could have the means to link the bits together as needed - so not entirely run time, but close. Single "JRE" would absolutely be important for memory and performance reasons.

I've presented ideas on this before at GWT gatherings (server side linking), but I think you're underestimating the difficulty of making this work, and making it work at scale. I encourage you, if you have a workable design, to engage with steering committee members to see if anyone is interested in implementing it.

These are all issues the Steering Committee members can take up, I'm not a member of the SC any more, these are just my opinions.

-Ray

 

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/af96cfa8-778a-467a-af96-2569065a4cea%40googlegroups.com.

[Learner Evermore]

I'm not sure I understand. If you use JSweet, it is very likely to break on using libraries from the Java ecosystem, which breaks a huge value proposition of using Java in the first place. It doesn't even support static field initialization and class initializers with proper semantics last time I checked. Someone who has learned Java will be very surprised at weird failures in the pipeline. GWT has parts of the JRE it doesn't support, but from a language level, it passes most of the JLS spec with some exceptions around numerics, overflow checks. My advice is, if you need a language with types and good IDE support that maps to JS, use TypeScript or Kotlin. Kotlin every has a great Java interop/JVM ecosystem story and amazing IDE support. 

Well, you are making the same point I am now. I am *NOT* advocating JSweet here, just that GWT does not deliver a better solution in this aspect than JSweet ... or TypeScript ... or Kotlin.

 

I just checked the demos on Github, TeaVM's box2d demo loads 306kb of JS (when uncompressed).  WebAssembly version is ~500kb uncompressed. The GWT version is 148kb uncompressed. The J2CL Box2D demo we use internally, while not strictly an apples-to-apples comparison, is 35kb uncompressed. 

Quite possibly. But also have a look at here https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming  ... Yes, it is rather old now, but it is with GWT 2.7 and TeaVM has involved since then, it seems more so than GWT.

 

Yes, it's a whole program optimizer, but it's about 50% worse than GWT at pruning, and a lot worse than J2CL + Closure Compiler and it doesn't support code splitting.  Why should one care about readability? Because besides source maps, it makes it much more transparent what's going on AND it integrates with the rest of the ES6 module system very easily. Every Java file can become a ES6 module, and any JS file can simple require/import it as if it was any other hand-written JS. This makes it very easy for JS programmers to work with it (Inbox.google.com is 60% Java, 40% JS). It makes Java more of a natural, first class member of a JS ecosystem. If you like JSweet, this does the same thing, only much better.

I am not sure it does 50% worse - that seems an arbitrary number. I do expect GWT to do (a little) better, but a little better is not enough to offset other characteristics where GWT looses badly compared to other approaches.  As for readability... transparency of such code is temporary at best, as it may change at any time to accommodate evolution of both languages. That means that it isn't stable and cannot be relied upon. Finally, why would I want to do JS programming at all? The main point is to be able to do as much as possible in a better language and stay away from JS, not more. If I wanted to do JS, I'd do JS... or TypeScript... or JSweet ... or Kotlin... and I do not. I do not want that because it is Java code I can share and it is Java code that defines interfaces between what different teams produce much better than JavaScript and allows better code sharing with the server than other listed alternatives. I don't have a particular need to read Java bytecode, do I? And it works quite well, debugs well and even runs in the browser without plugins (Dragome, TeaVM, Bck2Browser). If I wanted readability, it would not have been JS I'd want it in. Also have a look at JavaPoly.js, ST-JS, ... There are many competing technologies right now.

 

 

Community can only do it if the foundation allows it.

The foundation allows it, but it's hacky. I showed how it could be done.  You can use a Generator + Linker combo to get async/await annotations in the output, and then invoke BabelJS from the linker to transpile the ES7 async/await calls back into ES5.

 

Hacky != allows it. It has to be stable, guaranteed possible.

Horribly slow and cumbersome != allows it. GWT is slow as it is. It *can* be made faster but instead of that the path of least resistance is chosen - getting rid of the important features that are hard to implement.

Delayed beyond the deadline of having to move on != allows it ... too late.

 

It the current, flawed (in my opinion) implementation. It does not need to do it this way. With simulation of synchronous execution even of asynchronous server requests for more code any call can become a split point. anywhere... and we can let the developer quite literally choose how to split code. A lot less analysis needed upfront, even though it may be useful as an informational tool to the developer.

Yes, any call can be come a split point, and we do that at Google on projects like photos.google.com, where every controller, every event handler, every widget, or every data request is a split point. But GWT doesn't support this, someone needs to significantly improve the CodeSplitter in GWT to make this worthwhile, otherwise, it will made total code size loaded in the first split point triggered worse.

 

There are two things to realize: (a) this is possible without rocket science and without runtime performance degradation and (b) slight expense of very slightly larger code is perfectly acceptable when the benefit is huge otherwise. Pay a little to get a lot. We have a very large product in which total size of all fragments is about 5M (uncompressed). Initial fragment is presently half that size and is very hard to get smaller. This is our foundation on top of which more modules are built, adding further to code size. Hope was that GWT will evolve as this is perfectly possible to address, but it did not. And, no, this is not a "web site" that needs SEO. This is *meant* to be a "single page app" for a reason. If code is loaded in careful selected coarse units there is very little performance degradation from loading. Leftovers don't need to exist as such, because they would be split as well and not handled the way they are today. 

 

I've presented ideas on this before at GWT gatherings (server side linking), but I think you're underestimating the difficulty of making this work, and making it work at scale. I encourage you, if you have a workable design, to engage with steering committee members to see if anyone is interested in implementing it.

I am not underestimating the difficulty of that. I have decades of software development/design/architecture behind me and have made OSes, optimizing compilers, analysis tools, etc. GWT is already doing this, but it is doing it both inefficiently (provable) and it does not store the result of analysis in a way that can be reused by someone else later. But I do feel that the needs of us who develop very large scale apps are underestimated and the importance of such a thing.  Right now we are re-running the GWT compiler every time we need to change (usually add) modules. That takes a while and requires us to include some form of all relevant source code even if we didn't want that.

Not sure how to "engage with steering committee members" beyond communicating in places like this, as I can find very little information from them too.

 

These are all issues the Steering Committee members can take up, I'm not a member of the SC any more, these are just my opinions.

Thank you for your time and effort. I am just hugely disappointed with the (lack of) attention to GWT and care of existing users of GWT. There are only excuses why not do something, no vision as to what to do beyond the miraculous and mysterious J2CL.

[Relja Pcela]

Can somebody please tell us who are the members of gwt committee and is there any meeting notes in the last year (or two) ?

[Thomas Broyer]

On Friday, May 19, 2017 at 10:35:29 AM UTC+2, Relja Pcela wrote:

Can somebody please tell us who are the members of gwt committee

That page is almost up-to-date: http://www.gwtproject.org/steering.html (Ray has been replaced by Bhaskar Janakiraman as he moved to the Inbox team –afaik–, and Stephen has moved to LinkedIn; just sent a PR to update it https://github.com/gwtproject/gwt-site/pull/239; there's some move going on on the RedHat front too, they'll update the page when it's settled)

 

and is there any meeting notes in the last year (or two) ?

They're coming: https://github.com/gwtproject/gwt-site/pull/173#issuecomment-300605780

Ping +colin ;-)

[Thomas Broyer]

Hi,

On Thursday, May 18, 2017 at 6:29:29 PM UTC+2, Learner Evermore wrote:

Hi there!

I am faced with having to re-think what we are doing in the company I work for with respect to GWT, existing and new projects and I am struggling, to say the least. We've been very much a GWT shop for years now and have used it to expedite the development of very large solutions and improve the end user experience. We did this and this was possible because:

1. There is (was?) a visible big name behind the technology - Google. There were regular updates and a lively community. 
   
   
2. It allowed us to share a lot of code between the client and the server properly and use a programming language suitable for very large software - strong typing, encapsulation/visibility control and all the works. JavaScript just isn't an option - it isn;t even a thought with all the enhancements they are making.
   
   
3. It allowed us to cleanly and efficiently segregate and encapsulate functional responsibilities of both business and representation code. We were able to create a foundation with clean APIs that other teams build their modules on top - and we bring those modules together. We can evolve that foundation and dramatically change it looks beyond just CSS because we encapsulated units of UI into widgets and we came up with the means to aggregate client-server communication from all modules into single requests/responses via serialization (we otherwise used GWT RPC very little - there is a single service with a single method in there).
   
   
4. It offered integrated code optimization and debugging tools with what seemed to be a promising future vision and dedication.
   
   

We've been following what is going on with GWT 3.0 and, admittedly, didn't like it. However, we were hoping that our problems are common and that it will become apparent that GWT 3.0 vision needs some adjustments. We've observed other people communicating similar perspectives to ours. Unfortunately, we've also seen little acceptance of these comments, little action and, essentially, no direction with respect to those beyond "waiting to see what happens with GWT 3.0". We believe that this effective limbo is, at least, a big part of the reason for frequent statements like "GWT is dead, past its time" and abandoning the technology simple because they have to move forward but are left behind.

I/we perfectly understand the reasons why one would want to do things planned for GWT 3.0. Removals of GWT RPC and widgets can simplify some code and increase the performance of the tools, among other things. At the same time, I believe that the perspective taken to decide what to do is wrong. Instead of finding ways to simplify GWT at the expense of making GWT-based products more complex and loosing any chance of being compatible with pre-3.0 code, efforts should have been focused on solving the problems.

Here's the thing:

• Google is the main contributor to the Compiler, by a very very wide margin (~99.9% of the code has been written by Googlers)
• Google is (slowly) moving away from GWT towards j2cl; they will disengage from maintaining the GWT Compiler (as we know it) in the coming years.
• This means either the community (as a whole, and this includes you) rolls up its sleeves and steps up to maintain the GWT Compiler; or GWT moves to using j2cl.
• Google moving from GWT to j2cl is due to several issues with the current design, and a shift in how they build webapps. The crux is to leverage JS developers' knowledge of browsers, and existing JS libraries and tooling (to avoid duplicating efforts); relegating Java (inside Google; though this is from an outsider's point of view, so I might be wrong) to those parts of the apps that you want to share between platforms.
• They tried to replace the JS-optimization pass of GWT with Closure Compiler (i.e. integrating the Closure Compiler into the GWT Compiler; the -XenableClosureCompiler flag, removed in GWT 2.8), but it was abandoned (I believe relying on internal APIs of the Closure Compiler made it difficult for updates; even within Google's monorepo as it involves different teams, but exacerbated in the opensource world, particularly with different release cycles). So instead they decided to split the GWT Compiler into different parts, first a Java to Closure-annotated-JS transpiler (j2cl), then using the Closure Compiler as-is.
• Interop with JS had to be better: people want to use existing JS libs (including, from Google's point of view, Google's own libs: maps, protobuf, libphonenumber, etc.) with minimal friction, people want to create JS libs out of Java code (from Google's point of view: share code with JS devs so they can leverage the Closure Library to build the UI for example, rather then reimplementing the Google UI style in both Closure Library and GWT widgets, like they had to do for Google Groups and Google Flights for example, but that doesn't scale), and everything should ideally be compilable in a single optimized bundled (with code-splitting).
  They introduced JsInterop 3 years ago, as a mean to both consume existing JavaScript (those interfaces could be generated from Closure-annotated JS) and to export Java to JS APIs, then they rewrote it 1.5 years ago.
  They tried to produce JS code that could be fed as input to the Closure Compiler along with other code (the -XjsInteropMode CLOSURE first, 3 years ago, then the -XclosureFormattedOutput introduced 2.5 years ago).
  
• They spent a whole lot of time trying to optimize the compilation process to be as incremental as possible (to speed up SDM): they first made generators incremental, but it has to be an opt-in and is not straightforward to implement, they however try to infer which files are needed by a given generator for a given input class, but this means accessing resource (non-Java) files using specific APIs rather than from the classloader; they introduced the concept of "libraries" (gwtlib) 3.5 years ago, to finally abandon them 2 years ago; then they tried a "compile per file" approach 3 years ago which I believe is the basis of the current incremental compilation; and they tweaked the various optimizations passed to be run in SDM to make it faster and faster.
  In the end, j2cl doesn't have generators, first because it translates one file at a time (afaik) with no "full world view", and because the Java ecosystem already has a tool for code generation: annotation processing (and most –if not all– other usages can be turned into preprocessors, that you run explicitly ahead of time). This leaves "caching" and staleness checks to something that should already be good at it: the build system (and Google's build system is really good at it; but for most developers outside Google, there's also Gradle which is really good at it).
• Wrt code-splitting; Google has completely rewritten it 5 years ago (GWT 2.5), and added many flags to help tune it, but as Ray explained, it's still not ideal. This is however an area that has seen tremendous work by the JS community, with great results (webpack comes to mind; making it relatively easy to use the PRPL pattern, something that's not possible with GWT; the Closure Compiler also has means to modularize its output, but afaik it's not as easy to use). I think it's a good idea to try to leverage those existing tools; I have no idea what that could look like though.
• Wrt GWT-RPC and Widgets, afaik, Google don't use them on new projects, and are slowly moving away from them on older projects. Speaking of Google Groups for example, it wouldn't surprise me if it were being rewritten in Angular as we speak, given the similarities in UI with the Google Issue Tracker (https://issuetracker.google.com/), and it might be one of the last Google asset still using GWT-RPC.
  What that means is that Google no longer contributes to them, which means that we, the community, have to decide what to do with them.
  GWT-RPC is still very-much achievable with j2cl, either with some changes to move to an annotation processor, or with a preprocessor that would scan the whole classpath (and source code?), to generate the appropriate Java code. The questions are who will do this work and maintain it? There are people in the steering committee who love GWT-RPC and don't want it to die (hi Colin ;-) ), so there's still hope that there will be some form of GWT-RPC in GWT 3.0.
  As for widgets, it might very-well be possible to port them to JsInterop; one question is how to do it (switch to elemental2-dom? or port com.google.gwt.dom to JsInterop?).
• Then there are permutations. We decided a long time ago that it would be great to remove the user.agent-based permutation, or limit it to 2 permutations (modern browsers and oldIE; though with Microsoft finally abandoning oldIE –yay!– we could possibly go with only a "modern browsers" thing), but again it's a lot of work; and it might actually the main "blocker" for porting widgets. Ideally, the only "permutations" left should be i18n. But even without "removing" permutations, it should still be possible for GWT 3; for that, we need to experiment, which means we need to get our hands on a (preversion of) j2cl. Hopefully this will be the case by the end of the quarter.
• Finally, there are linkers. Linkers will likely have to be rethought out from scratch, but are likely to still be there in some form or another (there will still be i18n-permutations to choose from).

 

I know that these problems are hard, but they are also possible to solve. I know because I made solutions to similar problems. Yes, new GWT may produce code faster and it may produce faster code and it may interoperate better with the browser and JavaScript. But consider the following:

1. For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
   
   
2. For sharing code with the server, some people use node.js (I do not subscribe to this) but there are other options - JSweet, TeaVM, possibly Dragome and others.
   
   
3. For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly.
   
   
4. If one is forced to use external frameworks for serialization they don't get any benefits from GWT that other alternatives don't also get.
   
   
5. In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries...
   
   
6. If we're to work directly with the metal, similar to how JavaScript frameworks do things, then again - JSweet may be a better fit, possibly TeaVM. Neither has widgets in a sense GWT does/did.
   
   

Put it simply, GWT 3.0 does not seem offer a path for existing users,

Who said that?

 

does not have much novel for brand new users that isn't already available othewise and better, takes more time to do whatever it does and slows down the development and is losing trustworthiness - what guarantees that, if I start with GWT 3, I won't be left stranded when GWT 4 comes out... if it ever will?

Nobody can guarantee anything (did you see a contract somewhere?). Tell me about Silverlight, Adobe AIR, Flash(?) All backed by big companies in their time.

When it comes to opensource software, one way is to contribute.

If it's critical to your business, one way of contributing is to actually pay developers to work on it.

 

So, who is GWT 3.0 for? Who will use it?

Google won't be using GWT proper, they'll be making j2cl, jsinterop-generator, jsinterop-base and elemental2, and will contribute to the Java Runtime Emulation library (it is still in discussion where this code will live).

GWT 3 will have to bring j2cl+jremul+closure-compiler together into a coherent tool, resembling GWT 2, with a similar (but hopefully better) way of compiling and debugging the code (people who want more control could use the parts separately, like Google will).

I really hope the biggest change from GWT 2 will be the removal of generators (and linkers?) and GWT.create()-driven permutations.

Does this mean that there really is no vision about how GWT can truly evolve and grow? If so, let me offer some of my challenges that would be best solved or need to be solved in GWT, in no particular order.

1. Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work.
   
   
   
2. Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package.
   
   
3. Separate widgets into an optional module but definitely keep them going. They are important. They are used, both directly and via 3rd party libraries.
   
   
4. If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
   
   
   
5. Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules. 

2. Deferred binding and code generators are something we do not use directly as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too.
   
   
3. JSNI methods in comments were nice but are the only thing that truly requires the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni
   
   
4. Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective).  We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new.
   

One idea: export your public API with JsInterop, generate stubs to consume the API using JsInterop, provide both a JAR with bytecode and sources for the stubs (standard GWT library), and the compiled JS for the lib (minified and partially obfuscated if you want it closed-source)

 

2. Clean up the tooling. Stop embedding everything in a single monolithic jar, update code coverage tool support. Rethink debugging - perhaps leverage existing work done outside GWT for this? Separate the classpath of the compiler from what it is supposed to compile. These are not the same thing and cause grief.
   

Do you have the slightest idea what amount of work that represents?!

Given that Google won't do it (on their own dime), it'd be highly unlikely that it'd be free or even opensource.

As a business, you can choose to put your money on a commercial product, or on people to contribute to opensource projects (either dedicating employee time to such contributions, hiring people to work fulltime on it, or giving money to developers who would like to do it on their own but need to be supported).

 

Without the above, what seems to be a closer alternative to existing GWT 2.x users is a separate fork of GWT (that may not be coming any time soon) or a TeaVM enriched with a fork of GWT widgets and a module doing GWT RPC (possible!). It does not have code splitting support (yet) and, likely, no desire (or need) for "permutations" and related concepts. That would require widget libraries to be rewritten with that in mind, but that would be possible and would, it seems, yield a better dev environment with a better performing end result.

I don't want to see GWT fail. We have our future depending on it and, if we can't use it, I presently don't know what we can do. But we cannot use GWT 3.0. Remember - "I don't need it" is not the same as "Nobody needs it" and "shouldn't need it" is a matter of perspective typically uttered by those who don't create projects as complex as many of us others do.

First, GWT 2.x is not dead yet or for the foreseeable future.

So, what would you need (must-have, not nice-to-have) in GWT 3? A clear migration path (hopefully as automated as possible) from GWT 2?

[Thomas Broyer]

On Thursday, May 18, 2017 at 9:37:58 PM UTC+2, Relja Pcela wrote:

It would be really nice to see some new answers on this kind of questions from GWT contributors other than: "We don't know how GWT3 will look like in this moment but we know that J2CL will not include this and that" because this sentence is almost 2 years old.

We don't really know how GWT 3 will look like, but we know we'll base it upon j2cl, which means no JSNI and GWT.create() magic (no generators, no deferred-binding configuration in XML files).

We've said repeatedly that we were waiting to actually being able to start playing with j2cl to have a better understanding of what would be possible or impossible, what would need to be done, etc.

We want to start prototyping things.

And only then we'll be able to form a better image of what GWT 3 could look like.

Incidentally, you've had 2 years to start planning for it:

• remove as much JSNI as possible, leaving mostly one-liners that could then easily be replaced with JsInterop (and now that JsInterop is here with a beta of Elemental 2, that last migration can be started too)
• replace <replace-with> in gwt.xml with System.getProperty("…") and a switch…case (or if/else for more complex cases); this is relatively straightforward and can possibly even be (partially) automated (first step: generate, from the XML, a proxy class whose constructor does the switch on implementation, and replace the <replace-with> rules with a single one using the proxy class; second step: generate a static factory with that same switch code, and use it instead of the GWT.create())
• replace generators with annotation processors (first step: have the processor generate a *.gwt.xml file with <replace-with> rules; second step: rpelace the GWT.create() calls) or preprocessors (or a combination of both).

GWT-RPC is problematic, but not insurmountable. People (me included) question whether this is a good idea though, but others disagree.

We haven't seen the community engaging much in any discussion trying to move things forward though: if I tell you GWT-RPC won't be the same, can you tell me how you'd like it to be? (a preprocessor? a whitelist of classes in annotations on the RemoteService interfaces? what if it generated server-side code too instead of the serialization policy files?)

Fortunately, there have been people trying new things though (autorest for example).

UiBinder and ClientBundle have their issues, too; but maybe they need to be replaced with new tools leveraging the new toolchain, along with automated migration tools?

Regarding ClientBundle, isn't it now seen as a bad practice (with HTTP/2) to bundle assets inside the JS code?

[Learner Evermore]

So... If I read this correctly... Google has discovered that GWT is not good enough (is bad) to continue using it. It is creating a J2CL that produces readable code so that it can completely abandon its original Java source and continue without it. The already slow involvement will turn into no involvement at all. In fact, there may be no incentive at all to release that J2CL ever - as soon as it becomes good enough for Google to have a bit manual work left on the generated code it won't need it any more. If we exclude Google, who does not plan any future with GWT, steering committee is composed of representatives from Vaadin, RedCurrent, RedHat, Bizo and JetBrains. I truly may be mistaken but, other than perhaps Vaadin, I don't see any company (that I am familar with) that does anything of large scale with GWT. and may not have too much interest in particular GWT future either.

Google's Closure is effectively saying "Closure is "better" than GWT". Other technologies that are already available may also be better for focused needs - some of which I mentioned in my posts above. Coupled with the steering committee composition, it paints a very bleak picture of GWT 3 future, if any, ever. 

I will say that the appeal of GWT wasn't writing Java in the browser. That was only a part of it (and most of the complexity). It is about being able to share a lot of code between the client and the server with all the magic in between handled. No other existing solution handles that, including the GWT 3 with any RPC replacement addons. Why? Because it requires writing a ton of boilerplate code and annotations to turn one set of objects into another and back and does not allow reusability.

Making GWT better is possible. I am truly sorry that people haven't realized how and decided to, instead, focus on efforts to migrate away from it. That is what GWT 3 seems to be - a migration away tool (to Closure). This late in the game and without organized efforts it will be very hard to organize "the community" to do something about this, even if willing to pay. And it is not a good investment for any one company to pay for development of own framework here, so that won't happen either - it would be more work than to move away likely.

I am truly and utterly disappointed.

[Learner Evermore]

My responses to specific points:

Removing JSNI, <replace-with>, generators... we ourselves were careful enough to either never use some of these and/or to abstract and encapsulate their use. However everyone here seems to take the perspective of "it is just one product of one company that is affected". It isn't. Some of us have our customers who develop additions too. Even if we have code to clean up and clean it up, it still renders the solution incompatible with add-ons created by others. There is *no* migration here. Customer buys a foundation (A) from one company and add-ons (B) and (C) from two other companies. They then upgrade (A) to (A2) and suddenly (B) and (C) don't work. They cannot and won't just ask for new (B) and (C) - this may not be possible for business or technical reasons. Migration is not a model at all. It is a complete breakage.

GWT RPC itself has a lot of problems but the central part of it that cannot be done efficiently outside the core compiler without hooks made specifically for this is the serialization of restricted-visibility fields of classes made by third parties. Yes, it could be addressed by uet another preprocessor but why-oh-why do this? TeaVM does not do this but allows for it to be made using Metaprogramming API. Otherwise, serialization-related analysis of GWT is presently horribly inefficient and can be done really well - it does NOT need to be slow like some were saying., It is slow with the current design - that much is certainly true. Whitelisting (yes) and annotations are valid approaches. For example, w/o better approaches one could use *.gwt.xml to whitelist if not do it from annotations (which would be better). This really does not need to take significant time at all.

I am a little thin on UiBinder... can't talk much about it other than, perhaps, also provide ways for this to be optional and a separate module during compilation.

ClientBundle - whatever it is or isn't, it was a way to encapsulate styles in widgets and do other things. See my comment on migration not being a model for large cases. Being able to access resources is a part of Java, one way or another ... and this would form yet another thing that wasn't quite Java but is close... and is getting lost too.

Re: "First, GWT 2.x is not dead yet or for the foreseeable future."... How's that? Maybe it isn't dead but it seems to be on deathbed, with very little life support and no (communicated) vision of future at all. All we have is that it isn't GWT 3 and that GWT 3 is significantly less than GWT 2 but with J2CL and somewhat better JavaScript interop that may or not be important.

Re: "Do you have the slightest idea what amount of work that represents?! Given that Google won't do it (on their own dime), it'd be highly unlikely that it'd be free or even opensource." ... Yes, I actually do. Do you have any idea how much work that would save? I don't need a solution that does not reduce my work. GWT 3 increases that work. With respect to free/opensource - I can't comment on that as I can't predict future but I tend to agree for other reasons. Otherwise, there are much more complex open source and free solutions oht there. Some are funded by the sponsor companies who they benefit, some aren't but there is a set up guidance. You say "Incidentally, you've had 2 years to start planning for it..." but that is not really the case as there was this illusion that there existed a body that actually cares about what happens to existing users *OR* GWT 3 in general. At the same time there were announcements that 2.x will continue and that there is a steering committee, so there were hopes that it will realize the importance of things being dropped. Incomplete, unclear and downright misleading communication and ignorance of current users brought us here. Sure enough, I agree that Google does not need to foot the bill for this if it doesn't care, but I would have appreciated some more honesty.

[Thomas Broyer]

On Friday, May 19, 2017 at 2:45:37 PM UTC+2, Learner Evermore wrote:

So... If I read this correctly... Google has discovered that GWT is not good enough (is bad) to continue using it. It is creating a J2CL that produces readable code so that it can completely abandon its original Java source and continue without it. The already slow involvement will turn into no involvement at all. In fact, there may be no incentive at all to release that J2CL ever - as soon as it becomes good enough for Google to have a bit manual work left on the generated code it won't need it any more.

Google didn't have any incentive to release GWT 10 years ago, or to continue maintaining it in the open source. They've always been the main drivers and main contributors so they could have stopped sync'ing their internal repository to the outside work long ago; but they did just the opposite 4 years ago, with the opensource repository being the source of truth and them sync'ing it into their internal repository (they have a few internal patches, such as completely removing the legacy devmode).

You're just being pessimistic here.

 

If we exclude Google, who does not plan any future with GWT, steering committee is composed of representatives from Vaadin, RedCurrent, RedHat, Bizo and JetBrains. I truly may be mistaken but, other than perhaps Vaadin, I don't see any company (that I am familar with) that does anything of large scale with GWT. and may not have too much interest in particular GWT future either.

RedHat publishes the Errai framework, and has several tools built using GWT (including their JBoss/Wildfly admin console if I'm not mistaken)

RedCurrent is actively using GWT (no idea how and where), and employs (at least) 2 of the most productive contributors.

ArcBees (which you didn't cite) maintains the GWT-P framework.

There once was representatives from Sencha (Colin, then Justin), but they're apparently putting an halt to GXT (no new development at least), and the representatives have left the company.

 

Google's Closure is effectively saying "Closure is "better" than GWT".

The Closure Compiler is doing a better job at optimizing JavaScript. Even if it were doing a slightly worse job, using it means freeing development resources to work on something else.

Closure is only a part of the whole (future) toolchain though.

 

Other technologies that are already available may also be better for focused needs - some of which I mentioned in my posts above. Coupled with the steering committee composition, it paints a very bleak picture of GWT 3 future, if any, ever. 

I will say that the appeal of GWT wasn't writing Java in the browser. That was only a part of it (and most of the complexity). It is about being able to share a lot of code between the client and the server with all the magic in between handled. No other existing solution handles that, including the GWT 3 with any RPC replacement addons. Why? Because it requires writing a ton of boilerplate code and annotations to turn one set of objects into another and back and does not allow reusability.

Why would it necessarily require a ton of boilerplate code?

Also, "handing all the magic in between" makes it way too easy to produce inefficient code in terms of network usage.

[Learner Evermore]

Google didn't have any incentive to release GWT 10 years ago, or to continue maintaining it in the open source. They've always been the main drivers and main contributors so they could have stopped sync'ing their internal repository to the outside work long ago; but they did just the opposite 4 years ago, with the opensource repository being the source of truth and them sync'ing it into their internal repository (they have a few internal patches, such as completely removing the legacy devmode).

You're just being pessimistic here.

I did't expect GWT 10 from Google. I understand that. But if you decide to expose something to the market at least clearly communicate the intent once you want to stop it. We haven't had that.

 

RedHat publishes the Errai framework, and has several tools built using GWT (including their JBoss/Wildfly admin console if I'm not mistaken)

RedCurrent is actively using GWT (no idea how and where), and employs (at least) 2 of the most productive contributors.

ArcBees (which you didn't cite) maintains the GWT-P framework.

There once was representatives from Sencha (Colin, then Justin), but they're apparently putting an halt to GXT (no new development at least), and the representatives have left the company.

RedHat/Errai seems to use GWT internally only, not expose it directly, but I may be wrong.

RedCurrent - I have no idea.

ArcBees GWT-P is only about the client-side. There are many alternatives to that.

Sencha - I actually saw that as we are using GXT too. They also communicate vague but different picture. If GXT is truly out (and indications are that it probably is) that only means worse, whether GXT is of interest to someone or not - it means that they could not influence GWT on behalf of its customers.

Who is there using GWT fully, exposing it downstream and not limiting it to own codebase?

 

The Closure Compiler is doing a better job at optimizing JavaScript. Even if it were doing a slightly worse job, using it means freeing development resources to work on something else.

Closure is only a part of the whole (future) toolchain though.

I don't have a problem with Closure. That is fine. It may even be a great idea to leverage it do Java to JavaScript (or other target) conversion. But that too was vague and, it seems, will be a one-shot deal - to get off the Java code. It will address the client only and not nearly as efficiently as we know is possible.

 

 Why would it necessarily require a ton of boilerplate code?

Also, "handing all the magic in between" makes it way too easy to produce inefficient code in terms of network usage.

 

For every class that was made GWT-serializable by someone else we have to write code to wrap it in our own/new serialization frameworks. That may not be possible because we may not have sufficient access to their code and data and because we may not even be aware of their code. We'd have to introduce additional requirements to them and standard that they would have to follow and our compatibility with what they have written already goes down the drain. Joint customers don't have a path forward. We may not be able to communicate our and their objects together, in single request/responses roundtrips and may need to split them. That split introduces inefficiency. So instead of using optimized, efficient code created by everyone for this purpose, we are forced to eliminate that efficiency and break encapsulation and write more boilerplate code that runs slower. This is making it easier to translate code to JavaScript but has nothing GOOD to do with efficiency. If something is needed, it is needed. You can't just write it off and say that it is more efficient without it. Without it it does not work and would need to be replaced with something else. You think that something else will be more efficient? Think again. You think that developer time is cheaper than tool time? I know you don't. But this perspective may have been missed in GWT future planning.

I wonder if there is a way to identify other heavy GWT users that actually have a vested interest in its future... The approach can be better than anything else on the market, but the ball is being dropped. I realize it may be too late to pick it up. Just thinking.

[Learner Evermore]

Is there a way I can access J2CL code? Not open source? 

[Ray Cromwell]

On Fri, May 19, 2017 at 5:45 AM, Learner Evermore <learner....@gmail.com> wrote:

So... If I read this correctly... Google has discovered that GWT is not good enough (is bad) to continue using it. It is creating a J2CL that produces readable code so that it can completely abandon its original Java source and continue without it. The already slow involvement will turn into no involvement at all. In fact, there may be no incentive at all to release that J2CL ever - as soon as it becomes good enough for Google to have a bit manual work left on the generated code it won't need it any more. If we exclude Google, who does not plan any future with GWT, steering committee is composed of representatives from Vaadin, RedCurrent, RedHat, Bizo and JetBrains. I truly may be mistaken but, other than perhaps Vaadin, I don't see any company (that I am familar with) that does anything of large scale with GWT. and may not have too much interest in particular GWT future either.

No, Google is not converting all Java to JS to abandon Java, it's the exact opposite. Google needs to support 4 platforms with it's code: Web, Android, iOS, and Server. We share code by using Java. 60-70% of our code base is Java, which we transpile to Objective-C with J2ObjC, run natively on Android and the Server, and compile to the Web with GWT, and now J2CL.

But the Gmail team is 12 years old, we have a vast codebase that includes a lot of JS. We did not want to reimplement all of our existing Gmail code in Java and port all the widgets, nor did we want to recreate some kind of portable UI between Android, iOS, and Web like React-Native. In our opinion, the "Swing" approach leads to an Uncanny Valley effect, and the best approach is to use "native" UI for each platform. 

So for our hybrid apps, the business logic is Java, and the UI layer is a mix of JS and Java, Objective-C and Java (iOS), or just Java (Android).

For this to work, we need very low impedance JsInterop, hence we created the JsInterop spec, and added -XclosureFormattedOutput to GWT, so that we could feed the output of GWT into Closure compiler along with JS libraries and get a single, statically linked and optimized, output. This saved well over 500k out of a 2mb JS when first implemented. It also yields type-checking between JS code and Java, so if you make a typo or pass in a wrong argument from JS or vice versa.

But GWT had three pitfalls:

1) It optimizes twice in this scenario, once during GWT compilation, and again with Closure Compiler.

2) It creates a monolithic target. We don't want monolithic targets, we want compose.js to only have to depend on a few Java files like Compose.java. GWT code splitting does not offer deterministic fine grained control over what lands in a JS module.

3) GWT "closure formatted output" is still very unfriendly to Closure, it doesn't output interfaces, doesn't output any JsDoc, has weird conventions around class setup and the way cast checks work.

J2CL addresses all of these, it stands for Java-to-Closure, like J2ObjC stands for "Java to Objective C"

1) It works like Javac, it translates a file at a time, very fast, can recompile as soon as you hit save in your IDE

2) It produces standard ES6/Closure modules, and fully typed, fully conformant Closure inputs

3) It relies on standard Java mechanisms for generators and permutations (System.getProperty()/@define in Closure and APT)

4) It uses the build system to define split points. If you say target ABC in your build has Foo.java and Bar.java, then that JS target has those outputs (unless Closure moves them for being unused)

5) It can interop with the entire JS ecosystem with little effort, you could make Node JS modules from Java and deploy them via NPM if you were inclined (it would take a little bit of hacking to remove the Closure library dependencies tho). You could put Java into ReactJS/Native projects if you want.

GWT does too much, conceptially it is

1) a build system that tries to manage dependencies and run code generators

2) a linking system for assembling deployable JS to serve

3) a Java to JS translator

4) a Java optimizer

5) a JS optimizing compiler

6) a giant SDK runtime

We have decided to break this apart into lots of module pieces and replace what we're duplicating from existing ecosystems

1) use existing build systems to do what GWT is doing internally with it's module system and dependency checking

2) A standalone Java to JS translator as a separate build step (J2CL)

3) A standalone JS optimizing compiler as a separate build step (Closure Compiler)

4) a small runtime (JRE, Elemental2)

5) A good interop layer for tying this to any SDK runtimes you want (Polymer, Angular, React, Ember, GWT SDK, etc)

We've done what you're asking in effect, which is to break GWT up into modular pieces, you just don't like the fact that this creates incompatibility. But the foundational pieces, when they land, can be used by the community to reconstruct a GWT 3.0 that is much simpler to understand. 

* Much of the GWT SDK can be back-ported to JsInterop like we've done with a lot of the JRE.

* Someone could make a harness that makes GWT Generator APIs to APT's APIs, which could allow GWT generators that don't depend on global knowledge to run as APT. (e.g. the I18N, ResourceBundle, and perhaps UiBinder could run under the APT environment). GWT-RPC can't because it requires all sources to be present, it depends on global knowledge, so it would need a specialized preprocessing step that depends on the transitive closure of all of your dependencies. Still doable, but not as an APT.

* GWT.runAsync() can be replaced with Closure modules. We do this at Google, we have Dagger injected classes that return ListenableFutures (Promises). Behind the scenes, these either use GWT.runAsync(), or J2CL Closure Compiler modules, it's hidden, e.g.

We share more code between platforms with J2CL and JsInterop than we've ever shared with any GWT app before, because we're running code on Android and iOS now too.

We didn't make this decision lightly, it took years. We did this based on actual experience of trying to achieve it with GWT on some of the largest and oldest and more complex web apps there are for 2 years. Our app has millions of lines of code we have to handle a billion users. We didn't abandon Java on the Web, J2CL does not represent an abandonment of that approach, it represents a reboot of it in a conceptually cleaner model not tied to decisions made in 2004 and the need to support IE6.

-Ray

--
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+unsu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/744d8ab0-d243-4ba3-bce4-54ebe48053c3%40googlegroups.com.

[Learner Evermore]

No, Google is not converting all Java to JS to abandon Java, it's the exact opposite. Google needs to support 4 platforms with it's code....

OK, that is almost calming.

 

But the Gmail team is 12 years old, we have a vast codebase that includes a lot of JS...

That is fine. I understand and respect that.

 

In our opinion, the "Swing" approach leads to an Uncanny Valley effect, and the best approach is to use "native" UI for each platform. 

I am not sure what do you mean by "Swing approach". Maybe you are thinking of widgets? Well, the "native UI" boils down to communicating with hardware and populating video memory, etc. Is that the best way? It is the fastest. But it is also a lot of work. And zero abstraction. If your platform changes the look and feel, your product running inside it won't. As I mentioned before, it isn't just about CSS. It is about behaviour and UX paradigms as well. Widgets are a great abstraction that allows complete separation of concerns. Maybe they don't perform the fastest but that may be more important for games. And even though there was GWT Quake a while ago, it isn't GGT but GWT, with slightly different implications. In any case, my opinion is that both approaches should be possible. We are staying away from direct HTML DOM manipulation and have abstracted wherever possible, with no user-discernible performance difference, yet it allowed us to evolve very quickly and very compatibly. 

 

So for our hybrid apps, the business logic is Java, and the UI layer is a mix of JS and Java, Objective-C and Java (iOS), or just Java (Android).

In our apps we are 99.9% Java, with some JS where we had no choice. 

 

For this to work, we need very low impedance JsInterop, hence we created the JsInterop spec, and added -XclosureFormattedOutput to GWT, so that we could feed the output of GWT into Closure compiler along with JS libraries and get a single, statically linked and optimized, output. This saved well over 500k out of a 2mb JS when first implemented. It also yields type-checking between JS code and Java, so if you make a typo or pass in a wrong argument from JS or vice versa.

I understand and appreciate that. But brute force compaction will only get you so far. At some point you come to a situation where this no longer works and you have to split code. And that isn't a bad thing. Users access different area of application at different times, not all of it at once. Having a little code loading as they enter an "area" of the app for the first time isn't so bad. But the approach *can* scale very well. Will there be a small performance hit? Yes, but only the first time they click and only a little. There has to be no (none, zilch, nada, zero) performance difference thereafter, not even a little.

 

But GWT had three pitfalls:

...

J2CL addresses all of these...

That is good, I understand, respect and have nothing against that.

GWT does too much, conceptially it is

...

We have decided to break this apart into lots of module pieces and replace what we're duplicating from existing ecosystems

That too is good. That isn't the problem.

 

We've done what you're asking in effect, which is to break GWT up into modular pieces, you just don't like the fact that this creates incompatibility. But the foundational pieces, when they land, can be used by the community to reconstruct a GWT 3.0 that is much simpler to understand. 

Well, there we go. It isn't so much that this "creates incompatibility" as much that it doesn't even begin to allow it in a remotely reasonable way, the way I see ... as you say yourself:

* Someone could make a harness that makes GWT Generator APIs to APT's APIs, which could allow GWT generators that don't depend on global knowledge to run as APT. (e.g. the I18N, ResourceBundle, and perhaps UiBinder could run under the APT environment). GWT-RPC can't because it requires all sources to be present, it depends on global knowledge, so it would need a specialized preprocessing step that depends on the transitive closure of all of your dependencies. Still doable, but not as an APT.

So, the compiler is going through code once but we need to make a separate pass through all of it instead of interacting with it. Furthermore, how do we make the compiler generate code that accesses private fields? As it is I see only three horrible ways:

1. Preprocess all *.java code and generate new *.java code with synthetic methods, then pass that new code to J2CL.
2. Generate "CL" code that can bypass Java visibility restrictions, hope J2CL doesn't change its code generation style.
3. Make our own J2CL.

Again, see TeaVM metaprogramming API Wiki, for example: https://github.com/konsoletyper/teavm/wiki/Metaprogramming for ONE reasonable alternative to this. We may still have to do separate discovery passes, but it it significantly reduces the rest of the work.

 

We didn't make this decision lightly, it took years. We did this based on actual experience of trying to achieve it with GWT on some of the largest and oldest and more complex web apps there are for 2 years. Our app has millions of lines of code we have to handle a billion users. We didn't abandon Java on the Web, J2CL does not represent an abandonment of that approach, it represents a reboot of it in a conceptually cleaner model not tied to decisions made in 2004 and the need to support IE6.

Yes, you do handle more users that the rest of us. But that does not mean that your apps are more complex.

So, simple questions that truly need to be answerable before GWT 3 can have any future for us with complex products... and I think for any future users too:

1. How to reasonably accomplish compatibility with existing code dependent on widgets (for example Sencha GXT - most should be aware of that)
   
   
2. How to reasonably accomplish GWT RPC serialization (all of it)?
   

I am sure others will have other questions, like UiBinder, etc. We don't use it so I don't need to ask those...

[Peter Donald]

On Sat, May 20, 2017 at 10:05 AM, Learner Evermore
<learner....@gmail.com> wrote:
> So, simple questions that truly need to be answerable before GWT 3 can have
> any future for us with complex products... and I think for any future users
> too:

As context: We have several largish code bases probably totalling just
over a million lines of client code in total although some of that is
generated. However our single largest codebase is only 338K LOC but it
does support a bunch of complex scenarios.

And from what we have heard so far GWT 3 will make our lives a lot
easier. On the basis of this we are looking at building the next
version of our suite in GWT3 which is likely to have at least a 15
year lifespan.

I do not disagree that there will be some period of adjustment and
some growing pain but the future looks brighter now than it has in a
while for the GWT project. I also will be first to admit the GWT
projects communication is not always the greatest ;)

> How to reasonably accomplish compatibility with existing code dependent on
> widgets (for example Sencha GXT - most should be aware of that)

We looked at this and it seems reasonably simple to get the Widgets
working under a pure jsinterop+System.getProperty world. Simple but
labour intensive. You could do it now if you wanted to prepare for
GWT3.

We use UIBinder extensively and that is probably easy enough to get
95% converted to APT. However I do recall there being a bunch of
scenarios where it becomes harder - although what they were slips my
mind atm. In that case we are likely to just implement the subset and
generate errors if there is any of those scenarios in our code.

I have no idea what shape the client bundles would end up in but I
suspect we would move to using wrappers for whatever tool bundled the
javascript be it webpack or closure (does it have a bundling tool?) or
whatever. I love some of the css-in-js stuff happening in javascript
land - (See https://markdalgleish.github.io/presentation-a-unified-styling-language
for an overview). I certainly see some significant advantages about
changing the way we do stuff here.

> How to reasonably accomplish GWT RPC serialization (all of it)?

It is unfortunate that you have used this feature but I can't see it
ever being implemented by google or the community at large. It is
likely that this is something you will need to do and it will be hard,
particularly arbitrary exceptions which we have found difficult to
whitelist.

Most frameworks based on language/framework specific serialization
strategies tend to fail, often due to the difficulty of interacting
from other platforms or difficult evolving code on the same platform.
Java RMI is largely unused these days. Maybe now is the time to move
to something different*.

Failing that you can stick with GWT 2.X if it fits your current needs.

* A few years ago "grpc" (another google project IIRC? based on
protocol buffers?) came about which looked like it may be a good rpc
solution but it never had a javascript client.

--
Cheers,

Peter Donald

[Learner Evermore]

Well..

We looked at this and it seems reasonably simple to get the Widgets
working under a pure jsinterop+System.getProperty world. Simple but
labour intensive. You could do it now if you wanted to prepare for
GWT3.

Everything is possible if we do not. Fork GWT or any part of it and make it our own. The problem is that then it has no common direction of evolution and it becomes proprietary. Even if we open-source that we're still disconnected from the main development and may stop working at any time.

 

We use UIBinder extensively and that is probably easy enough to get
95% converted to APT. However I do recall there being a bunch of
scenarios where it becomes harder - although what they were slips my
mind atm. In that case we are likely to just implement the subset and
generate errors if there is any of those scenarios in our code.

Good for you. May not be good for someone else (we do not use UiBinder). The problem we have is that we are not the last in line of dependencies. While, with some large effort, it is possible to migrate any code you own entirely to anything else, this isn't the case if you have downstream dependents in form of external customers and partners. We do.

 

I have no idea what shape the client bundles would end up in but I
suspect  we would move to using wrappers for whatever tool bundled the
javascript be it webpack or closure (does it have a bundling tool?) or
whatever. I love some of the css-in-js stuff happening in javascript
land - (See https://markdalgleish.github.io/presentation-a-unified-styling-language
for an overview). I certainly see some significant advantages about
changing the way we do stuff here.

Going forward this may be good for some. My previous comment applies here too. Even if we could "move", we cannot force others to.

 

> How to reasonably accomplish GWT RPC serialization (all of it)?

It is unfortunate that you have used this feature but I can't see it
ever being implemented by google or the community at large.

Why is it unfortunate? It works. It is efficient (code). It requires the least effort to use. It is NOT for the API but for internal communication.

 

Most frameworks based on language/framework specific serialization
strategies tend to fail, often due to the difficulty of interacting
from other platforms or difficult evolving code on the same platform.
Java RMI is largely unused these days. Maybe now is the time to move
to something different*.

Who says there is a need to interact with other platforms or languages? We do have other solutions for that. But we have/had a better approach for our internal Java-to-Java communication. We don't use Java RMI for the same reason we don't want the outer part of GWT RPC. That is, for us, replaceable. It is the serialization that is important. And, arguably, Java serialization is NO different than any other except:

• It encapsulates control of serialization in a common way for all classes and in the language syntax 
• Its wire format is (somewhat) flexible by using an appropriate (sub)type of object stream
• It works without having to code special access to default/private/protected fields or resorting to hacks that work around it
• It completely and safely matches the language semantics w.r.t. primitive and complex types and null (or undefined), etc.
• It works whatever frameworks different libraries you use use themselves

Sure, it does not put field names into the stream but that would be an inefficiency and not desirable in many cases. It is important for public APIs, but not for internal communication. Do NOT confuse GWT RPC with public API exposure framework. We all agree that it isn't for that, never meant for that.

[Learner Evermore]

... and before someone mentions version/compatibility issues with serialization (using any framework) not that NO framework solves this, they just have different ways of not solving it. And all frameworks expose *exactly* equal ways of dealing with it should one be interested. Including java.io.Serializable. And if you happen to not care and change things, it always results in errors (default cases excepted) only with java.io.Serializable you get that error immediately and with some other popular frameworks you get the error at the time of first use - hence less detectable.

[Paul Robinson]

As a heavy user of GWT-RPC in a large app, I've become disillusioned with it. That's for three reasons:

- 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.

- it's not good for communicating from a mobile app.

- 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.

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.

I just hope we don't have to give up widgets too. I don't see that being practical for us.

Paul

On 20 May 2017 2:56 pm, "Learner Evermore" <learner....@gmail.com> wrote:

... and before someone mentions version/compatibility issues with serialization (using any framework) not that NO framework solves this, they just have different ways of not solving it. And all frameworks expose *exactly* equal ways of dealing with it should one be interested. Including java.io.Serializable. And if you happen to not care and change things, it always results in errors (default cases excepted) only with java.io.Serializable you get that error immediately and with some other popular frameworks you get the error at the time of first use - hence less detectable.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/1eaced67-96f6-4ea0-9ef7-5bbabb2cf569%40googlegroups.com.

[Paul Stockley]

I have to agree. A long time ago we moved away from GWT RPC to an approach that used straight JSON. This forced on us by the poor performance on mobile devices. Right away we saw 3 to 5x speed improvement and significant code size reduction. Sure the developer experience wasn't quite as nice. However we, could hardly measure an actual hit in overall productivity. To be honest, our user experience will always take priority over developer UX. 

[Learner Evermore]

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"?

[Learner Evermore]

On Saturday, May 20, 2017 at 1:06:40 PM UTC-4, Paul Stockley wrote:

I have to agree. A long time ago we moved away from GWT RPC to an approach that used straight JSON. This forced on us by the poor performance on mobile devices. Right away we saw 3 to 5x speed improvement and significant code size reduction. Sure the developer experience wasn't quite as nice. However we, could hardly measure an actual hit in overall productivity. To be honest, our user experience will always take priority over developer UX. 

There is no runtime performance difference between GWT RPC and JSON if you do your homework that you were forced to do when you moved to JSON.  It does not exist. We can confirm that, given same functionality. You can't compare apples to oranges here. 

Yes, there is a difference in compilation time, but for that I entirely blame the inefficient GWT compiler implementation. It can, actually, be super fast, faster than using any other framework for the equivalent case. How/why? We can talk about that if there are interested parties, in a proper place. I have exactly the same comment for code size. Yes, that code size, affects loading time, so it makes things worse. But, again, it actually can be fixed, and if you did your homework right, it should not have been an issue unless, again, you are comparing apples to oranges in terms of functionality.

[Paul Stockley]

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.

[Learner Evermore]

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.

[Thomas Broyer]

On Saturday, May 20, 2017 at 2:05:22 AM UTC+2, Learner Evermore wrote:

 

In our opinion, the "Swing" approach leads to an Uncanny Valley effect, and the best approach is to use "native" UI for each platform. 

I am not sure what do you mean by "Swing approach". Maybe you are thinking of widgets? Well, the "native UI" boils down to communicating with hardware and populating video memory, etc. Is that the best way? It is the fastest. But it is also a lot of work.

"Swing approach", as in javax.swing, i.e. build a UI once and run it everywhere, with theming to try to blend it with the platform.

"native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's <button>, i.e. build the UI with the tools native to the target platform.

 

* Someone could make a harness that makes GWT Generator APIs to APT's APIs,

Fwiw, I had started working on it almost 2 years ago, and Daniel (Kurka) told me he went that path too, but eventually abandoned as it was relatively easy to port generators to annotation processors. And that was indeed my experience as well when porting the PlaceHistoryMapper generator over to APT as aprood of concept: https://github.com/tbroyer/gwt-places

I haven't deleted my own code though, so I could revive it if there's a real demand (but there's still a need to change the "contract" to trigger the annotation processor from a GWT.create() call on a subclass/subinterface to an annotation on that subclass/subinterface, so I'm not sure it's really worth it; possibly as a temporary step for very complex generators but even for that I doubt it)

 

which could allow GWT generators that don't depend on global knowledge to run as APT. (e.g. the I18N, ResourceBundle, and perhaps UiBinder could run under the APT environment). GWT-RPC can't because it requires all sources to be present, it depends on global knowledge, so it would need a specialized preprocessing step that depends on the transitive closure of all of your dependencies. Still doable, but not as an APT.

So, the compiler is going through code once but we need to make a separate pass through all of it instead of interacting with it.

In a j2cl+closure-compiler world, the *optimizer* (from many-files-JS to optimized-and-bundled-JS; i.e. closure compiler) goes through all the code, but not the *translator* (form Java to JS; i.e. j2cl).

From what I've been told, j2cl works at the file level directly translating Java to JS, so it does not (necessarily) see all the code.

The same is true to some extent with javac (though it needs to "see" the class dependencies, i.e. if class A uses class B, then it needs B to be able to compile A; afaict this wouldn't even be required for j2cl).

Btw, I'd really like it if for development only j2cl was needed, without the closure-compiler pass (now that most browsers support ES6 classes: https://caniuse.com/#feat=es6-class / https://kangax.github.io/compat-table/es6/#test-class ; assuming j2cl produces goog.require / goog.provide rather than ES6 modules, though ES6 modules are supported in all evergreen browsers behind a flag)

That would make debugging even faster (file changes, it's translated to JS by j2cl, refresh the browser and you have it) and even easier! (readable ES6 class code matching your Java code means you don't even need to use source maps, and you navigate inside the code similar to how you navigate inside your Java code, rather than through one huge JS file containing everything)

Furthermore, how do we make the compiler generate code that accesses private fields?

This is a very good question, and it seems like it would be the only blocker.

So, simple questions that truly need to be answerable before GWT 3 can have any future for us with complex products... and I think for any future users too:

1. How to reasonably accomplish compatibility with existing code dependent on widgets (for example Sencha GXT - most should be aware of that)
   
   
2. How to reasonably accomplish GWT RPC serialization (all of it)?
   

I am sure others will have other questions, like UiBinder, etc. We don't use it so I don't need to ask those...

Yes, those are the questions that still have no answer, that need to have an answer, and that are basically waiting for us to finally get our hands on j2cl and start playing with it. To start to grasp how we could build GWT 3 around it, what kind of toolchain to build (one integrated piece of software, or rather build system plugins tying them all together, etc.), what actual work would be needed to port widgets, and basically find answers to all those open questions.

Until then, GWT 2.x is here to stay for at least a handful years I believe, and we'll try (it'll depend on the effort it takes) to provide a smooth migration path from GWT 2 to GWT 3.

But we've kept repeating it, and will repeat it again for the few months to come: we don't know yet what GWT 3 will look like exactly (for example, for now, only people at Google can push releases to the Central Repository, and this needs to change so we can release smaller, more modular artifacts, more often, and that's needs to be discussed too, also who will be in charge of each of those modules now that they're gonna live their life separately, how to ensure they continue to work well together, etc.) It's as much organizational as it is technical. A lot of work ahead of us, and we hope that the community will come support that effort (and not just wait for it and complain that it's not coming fast enough, as it would be easy to do for any of us). Migration paths and migration tools (if any) will have to come (in part) from the people who need it most, such as those for which GWT is business-critical (and yes, that'll mean investing time and energy and endure the early problems).

[Learner Evermore]

"Swing approach", as in javax.swing, i.e. build a UI once and run it everywhere, with theming to try to blend it with the platform.

"native UI" as in Android's android.widget.Button vs. Cocoa's NSButton or UIKit's UIButton, vs. WPF's System.Windows.Controls.Button vs. HTML's <button>, i.e. build the UI with the tools native to the target platform.

Well, *we* don't do that. GWT widgets and the UI code that drives them that way is only for the web. Underlying code is shared, but not the actual presentation. However, the widgets do give us a level of abstraction and related freedom with respect to add-ons that others make for our product. We can evolve our product and have greater flexibility in changing how it looks and behaves when add-ons use our widgets as main building blocks. They bring main navigational and other user experience paradigms, not just looks which could be handled by CSS. With respect to various forms of buttons you mention as an example we would have abstracted that, not taken the javax.swing approach of reimplementing them. I do not know what others are doing.

 

 Fwiw, I had started working on it almost 2 years ago, and Daniel (Kurka) told me he went that path too, but eventually abandoned as it was relatively easy to port generators to annotation processors. And that was indeed my experience as well when porting the PlaceHistoryMapper generator over to APT as aprood of concept: https://github.com/tbroyer/gwt-places

I like APT better over the other form of generators too. My problem isn't about that exactly.In our case the problem is what do we do with 3rd party libraries we depend on that need whatever they may and, more directly, the fact that we cannot generate additional synthetic (de)serialization methods without regenerating the entire type - and we'd need to do that to gain access to anything that isn't public. No, not all fields should have getters and certainly not setters.

 

Btw, I'd really like it if for development only j2cl was needed, without the closure-compiler pass (now that most browsers support ...

I'd like the same thing for some other reasons too. I am mostly coming from the perspective of efficiently delivering and combining our code with add-on code at customer (install-time or run-time).

 

Furthermore, how do we make the compiler generate code that accesses private fields?

This is a very good question, and it seems like it would be the only blocker.

Yes. So, what we'd need is that this is at least allowed.

Thanks for the rest of the info.

[Paul Stockley]

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.

[Learner Evermore]

On Monday, May 22, 2017 at 8:32:34 AM UTC-4, Paul Stockley wrote:

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.

Where did I do that? I noted that you cannot compare approaches that don't yield equal amounts of functionality. I proved that these are apples and oranges.

 

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.

Try reading my comments again. I never tried to avoid work. The problems are that the effort really should be centralized to maximize benefit and, more critically in this case, it is not possible for anyone to make RPC work without appropriate hooks in the compiler. Quoting myself, excerpts from different posts:

• If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization

• Community can only do it if the foundation allows it.

• It isn't so much that this "creates incompatibility" as much that it doesn't even begin to allow it in a remotely reasonable way
  

[David]

I guess he is going through the same steps like most devs who relied on GWT. I recognise the same reactions I initially had. We also have huge applications build on GWT and we don't like rewriting hings that work.  But sometimes it is a good moment to reflect on the choices that were made. With Java 8 support in place I have the tendency to do things different anyway.

After working iwth JsInterrop and Elemental2 (and the ability to quickly interface with other js based widgets) I noticed that my code is much smaller and maintainable.

Right now I still depend on UiBinder and CellWidgets, but I plan to move too Elemento2 and possibly vaadin grid instead or bootstrap datatable.

Superdevmode is also fine in most cases. Sure sometimes it is a fight to put a breakpoint in the right location, but with pretty mode the mapping between js and java is very readable.

Now I just need a replacement for GWTP with annotation processors. If needed I would even like to help out in getting it done.

--
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-co...@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.

[Learner Evermore]

On Monday, May 22, 2017 at 2:55:01 PM UTC-4, stuckagain wrote:

But sometimes it is a good moment to reflect on the choices that were made. With Java 8 support in place I have the tendency to do things different anyway.

That is only possible if:

a) You have complete control over the entire codebase above GWT

-OR-

b) You have complete control over the entire codebase above GWT except for some libraries you use but that will address this internally.

-OR-

c) You have completely abstracted everything (GWT *and* any 3rd party libraries) from the code you don't control.

Case (a) can be plenty of work but is possible.

Case (b) could actually be less work than (a) but you may need to wait for 3rd party libraries to catch up. Will GXT catch up, for example? 

Case (c) does is plenty of work upfront and rarely done .

There are those of us who fall into none of the above. We have built upon GWT and have let others who build their solutions on top of our foundation enjoy it too. Trouble is that, even if we decide to implement the bits to-be-missing in GWT 3.0 ourselves, we can't. It isn't possible without official (but non-existent) hooks into the compiler. That is for GWT RPC. For widgets it is not possible for other reasons in a general case (but does not directly hit me as we haven't allowed anyone else to use JSNI or custom code generators- only foundation code uses a bit of JSNI where there was no other choice and that's it). However, it is a great big challenge as there are many GWT libraries out there that depend on this and that can't work at all without multiple of those bits - some paid, some free. 

[Anders Forsell]

I just want to chime in and let you know that in my case migrating away from GWT Material Design with UiBinder, JSNI and bundle resource in favor of JsInterop+Elemental 2 and the UI layer with Web Components/Polymer 2.0 took a couple of months.

There is a growing number of reusable web components at https://www.webcomponents.org/, with the Vaadin components like the vaadin-grid worth mentioning.

In the end it made my architecture much better with a clear separation between the UI layer and the Model/Presenter (business logic) layers in Java.

See more info in my G+ post: https://plus.google.com/+AndersForsell/posts/NpTm1Ga8eMM

I am now looking forward to the benefits in using J2CL and hope that Google continues to be open and share their work with the open-source community.

Anders

[Learner Evermore]

@Anders Forsell: We were careful to make a good separation between UI concerns in Java from the very beginning. We were very strict about this. So, a "forced opportunity" to redo this isn't a benefit to us.

Otherwise... if community is to help and roll up the sleeves we still need some things in the core of GWT. Without it things become essentially impossible for all practical purposes. Getting back to my original question - the business proposition/value let's consider different reasons I can enumerate why people used GWT in the past and what options they would have today:

1. Just wanted a typed, safe language to work with in the browser. 
   TypeScript + JavaScript has evolved itself .. and anything below.
   
   
2. Wanted a language in which dangerous undisciplined JavaScript code wasn't possible.
   It is always possible but it may be hidden under the rug. TypeScript with some validators, Kotlin and others. If you want Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT.
   
   
3. Wanted Java for sentimental reasons
   Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT.
   
   
4. Wanted all/most of Java RE/VM semantics
   Dragome, not sure of Bck2Browser and others. Not GWT - it may have a good chunk of classes emulated but not all of the semantics.
   
   
5. Wanted to share client-side code between web, mobile devices, etc. Not sharing anything with the server. Will abstract the presentation layer "myself".
   Kotlin, TeaVM, Dragome, Bck2Browser, ...and, yes, GWT. You will not use the HTML abstraction for all the platforms. All present platforms, including web/HTML do widgets. Depending on HTML on all is possible but, then again, it really is just a web app...
   
   
6. Same as above, but expecting that the presentation layer abstraction is already present (i.e. not "Swing" approach)
   Kotlin?
   
   
7. Sharing code between client and server
   This gets to be fun. What code do you want to share? Do you care about what language you run on the server? I am very far from being a fan of node.js but many use it, and it can be used with languages that can translate to JavaScript (e.g. TypeScript and others).
   
   If you want Java on the server then what code will you share? If you are only going to share classes that are NOT used for communication (DTOs are excluded here as they are not about code sharing but inherent necessity), then you really can use anything from (4) or (5). If you want to use Java communicate instances of shared classes then you either need to make the communication happen yourself (say via DTOs and 3rd party frameworks) but you become constrained as to what you can and need to do and what libraries you can use - because they need to be compatible in terms of communication. If you don't want to have to worry about this, but only about efficiency of communication and let the framework handle the wire transfers, then there you can use GWT 2.8.1 or older (not 3.0), TeaVM (you have to code a bit but it is possible) and, possibly, Dragome (not sure, but it does reflection too, so it may be possible to add if not already in). 

I may have missed some solutions out there and haven't listed all those that do apply in all cases but you get the point. Getting the benefit of Closure optimization will be possible with any JavaScript-based solution, including JSweet, TeaVM and possibly others (not Dragome as far as I know). In terms of controlling UI in the web, you can use whatever fills you heart with warmth if you like JavaScript approaches (Angular, React and many others) with almost any of these, perhaps best with JSweet if you want Java. 

So what are differentiators of GWT? Repating, to an extent, my first post here:

• J2CL? Not really. The same can be applied to most other approaches mentioned above.
• JSInterop? Not really. Other approaches have other, similar and even better integration (or no need for one).
• Presentation control? Matter of taste, but if one wants to get close to the metal, then there are ways to get closer and better. Widget-based approach is easier/safer to work with if one is to share presentation built on top of them between different devices or of, like we do, wants to abstract the foundation's appearance *and* behaviour from the code built downstream from us. Availability of libraries is questionable as all those that depended on GWT widgets go down the drain and have questionable future support.
• Size of code? Not really. TeaVM is close and can use the same optimization tool GWT will.
• Code splitting? Yes, if it survives, but others aren't far behind. With TeaVM this may be relatively a simple endeavour even across synchronous calls and without the "leftovers" issue.
• Permutations? Not really. These are not a benefit but a painful means to an end that isn't as needed as before and could be abstracted otherwise?
• Serialization, RPC? Non existent.
• Compatibility with existing code? No such thing in complex cases. There will be always something you need to rewrite. It may just happen so that, if you take a careful look, using something other than GWT may actually be better.
• I18N/L10N resources? We could not live with the number of permutations this creates so we have done thing ourselves, took it away from the permutations system. That shows the benefit of that.
• Tooling - i.e. debugging? Others have good, if not better, tools.
• Timing? GWT 3.0 does not exist yet. Others do and are, arguably, not sitting still.

I am personally willing to help but can only do so if there are provisions made to make things at least possible...

[Thomas Broyer]

On Tuesday, May 23, 2017 at 5:27:44 PM UTC+2, Learner Evermore wrote:

@Anders Forsell: We were careful to make a good separation between UI concerns in Java from the very beginning. We were very strict about this. So, a "forced opportunity" to redo this isn't a benefit to us.

Otherwise... if community is to help and roll up the sleeves we still need some things in the core of GWT.

Just because it wasn't mentioned yet in this thread, and I think it deserves some clarification: "the community" does not necessarily mean "third party projects on top of GWT"; GWT is open source and contributions are welcome.

J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.

Wrt debugging: Dragome uses asynchronous websockets to run your code in Java, similar to the legacy DevMode; except that DevMode was careful to be blocking and reentrant. With Dragome, if you set a breakpoint in your Java code, your browser continues to run and process events, which means things can go much differently in debug than in production (particularly as soon as you start using some JS code with its own event handling and/or network requests that doesn't reenter your Java code). If you go back in time when SuperDevMOde was announced to replace DevMode, you'll find many people asking whether Pepper could be used instead of NPAPI, or PNaCl, or WebSockets, etc. and all were dismissed for that single reason that they didn't allow blocking the main thread (by design). Debugging also apparently requires you to put Dragome into your webapp (with possible dependency conflicts) rather than have it live separately.

TeaVM apparently has it right, by hooking into the browser debugger, but it then requires a browser extension (one for each browser, as the debugging APIs and protocols aren't portable), and currently only has one for Chrome (actually, maybe Chrome is the only browser exposing a debugger API to extensions, I don't know). This also means you cannot debug a mobile device.

So, if those a fast enough (as fast as GWT SuperDevMode, or j2cl which I believe and hope will be even faster) and can produce readable JS, then you can get a similar experience to GWT SuperDevMode, though you'll never have sourcemaps has their input is bytecode.

So, there are trade-offs everywhere.

[Learner Evermore]

Just because it wasn't mentioned yet in this thread, and I think it deserves some clarification: "the community" does not necessarily mean "third party projects on top of GWT"; GWT is open source and contributions are welcome.

Yes, that is how I took it. But it isn't just "roll up the sleeves and do it" - it requires coordination and desire to do this, some sort of common guidance.

 

So, there are trade-offs everywhere.

Yes, of course. 

[Learner Evermore]

J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.

I didn't think much of this when I read this the first time but I just realized that for J2Cl you say "it'll be open source...", meaning it isn't yet... and it is likely the place where the modifications need to be made to, at the very least, expose necessary hooks to make things possible. That makes it impossible for the community to help (before it is open sourced).

[Hristo Stoyanov]

On Tuesday, May 23, 2017 at 12:57:35 PM UTC-7, Learner Evermore wrote:

J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.

I didn't think much of this when I read this the first time but I just realized that for J2Cl you say "it'll be open source...", meaning it isn't yet... and it is likely the place where the modifications need to be made to, at the very least, expose necessary hooks to make things possible. That makes it impossible for the community to help (before it is open sourced).

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. The GWT/J2CL team at Google already followed through with Elemental2 and the code generators, which by the way are shared with J2CL (smart!). However, they do have internal customers to win first and secure funding, since there are several internal Google web framework teams (Dart, AngularJS, Polymer, etc) each one claiming to be the "official Google web framework", competing for limited internal funding/resources.

Having said that my prediction is that GWT 3.0 plans will be quickly abandoned once the community gets its teeth into J2CL. This may sound harsh, but is a lot better than the Cambrian explosion of JS frameworks, which left 99% of them as dead corpses over the web landscape.  Google already issued DOs and DONTs to make the GWT-->J2CL transition easier.

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.

[Manfred Tremmel]

I think we all have different priorities in using GWT. I'm using GWT
since 2008 and worked on different internal GWT applications and a
Online Shop ¹) based on Hybris and GWT. Two other GWT projects are work
in progress, one should be released in October, the other one early next
year.

2014 I stopped using RPC for new projects and switched to REST, so I
will not miss it really. GWTP-RestDispatcher or RestyGWT feels nearly
the same as using RPC and keeps server side independend of GWT.

Widgets are something else. We all now, the integrated widgets of the
GWT project made no real progress the last years, HTML5 features are
missing (no placeholder, no required, no new input types, ...) and
validation integration is non existing. I think most of us have used
something else or build there own collection (like I did in ²)), so I
would not really miss the internal Widgets, but would miss Widgets as
base for own implementations and as base for the editor framework.

Very useful in my point of view are UI-Binder, the editor framework and
the validation framework (that's the reason why I've taken over the
deprecated bean validation into my gwt-bean-validators ³) project and
updated it to the validation-api 1.1.0 and hibernate-validator 5.4.1).
In combination this provides the best form handling of all frameworks I
know, and that's a core feature of all my applications. In combination
with the GWTP MVP framework I really like working with (architecture
details in combination with spring can be found on this wiki ⁴)).

The other thing is code sharing between client and server, this makes it
so easy to port functions from server to client side and provide offline
functionality.

¹) https://www.tecparts.com/
²) https://github.com/ManfredTremmel/gwt-mt-widgets
³) https://github.com/ManfredTremmel/gwt-bean-validators
⁴) https://github.com/ManfredTremmel/gwt-bean-validators-example/wiki

[Learner Evermore]

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." 

 

[John A. Tamplin]

On Tue, May 23, 2017 at 8:24 PM, Learner Evermore <learner....@gmail.com> wrote:

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.

Why is that so?  Can't you do your own whole-world analysis pass independently of the compiler if that is what you want to do?  It does not seem possible to have whole-world analysis in the compiler (hooks or not) if the goal is to enable separate compilation at the Java layer.  So, if that is important to you, it must necessarily be outside the compiler.

--

John A. Tamplin

[Learner Evermore]

On Tuesday, May 23, 2017 at 9:36:45 PM UTC-4, John A. Tamplin wrote:

Why is that so?  Can't you do your own whole-world analysis pass independently of the compiler if that is what you want to do?  It does not seem possible to have whole-world analysis in the compiler (hooks or not) if the goal is to enable separate compilation at the Java layer.  So, if that is important to you, it must necessarily be outside the compiler.

Well, think a little bit more about it yourself. Yes, I *can* do the analysis. I don't even need the source code for it, in fact. But what then? Code needs to be generated to perform (de)serialization as there is no reflection in the GWT client side. Fine. I could do that too but there are non-public fields without accessor methods (and, these are perfectly valid cases, and in fact, a good pattern). So how/where do you generate code that can both get/read and set non-public fields of any class? There are following ways about this:

1. Use reflection. But reflection is not available in the GWT client-side.
2. Generate code / synthetic methods within the classes they (de)serialize. But J2CL does not offer that.
   
3. Re-generate ALL code so that the new copy is a superset of the original - it includes both the original and new synthetic methods. Essentially a Java-to-Java compiler. But this would be much slower because it has to regenerate code in a file system somewhere so that J2CL has all of it, including those from imported libraries. Debugging also becomes interesting. You can't just generate new code to be equivalent functionally - you need to actually maintain exact formatting as it was before and add stuff at the end to avoid shifting line numbers. If you have nested classes this becomes impossible.
4. Like (2) but generating CL / JavaScript code instead and, thus, not having the issues of (3) and even being able to bypass Java visibility rules. As J2CL evolves and possibly changes how it translates Java to JavaScript this would have to evolve equivalently too.

So (1) is not possible, (3) is not feasible or possible / practical and (2) or (4) are both OK but require hooks in J2CL to integrate with the process. See https://github.com/konsoletyper/teavm/wiki/Metaprogramming for such a hook in TeaVM. TeaVM does *not* have RPC like GWT does but it makes it possible for it to be implemented externally via this API.

[Learner Evermore]

... continuing the above - there is more. Let's now come back to the analysis part. Yes, it is possible to do the "whole-world analysis" outside the compiler. But what perspective should the analysis take? It is irrelevant if it cannot reduce the number of possible classes - we don't want all of Java runtime library in there, for example. We need to discover which parts are needed from the code that *could* be executed. GWT determines this based on entry points and other configuration in the *.gwt.xml files *and* what it finds in the compilation classpath, as configured, including its own version of the standard library. So, the pre-compilation analysis tool would have to configured exactly the same and process exactly the same configuration as the GWT compilation step. This would have to evolve in lockstep with GWT. It would also be doing the same processing and analysis that GWT already has to do - at least the step of deciding which bits of code to convert to JavaScript before any further optimization. 

Are we done with that? Whether or not you think that this still can or should be done outside and with no integration with J2CL, let's move on to the debugging. How about *any* dev mode where the code is to be automatically updated on demand? What event signifies that demand? When can we trigger that analysis and code gen step before, say, the Super Dev Mode of the future gets hold of the code? Again, without any ways to hook into that, we'd be relying on the analysis and code generation already having been done by the time SDM has to do anything with it and that means either manual triggering or something like "on save", if that can be monitored (not reliable). And how would that pre-step be configured by the developer? Duplicating configuration but possibly in a different way?

[John A. Tamplin]

On Wed, May 24, 2017 at 1:14 AM, Learner Evermore <learner....@gmail.com> wrote:

... continuing the above - there is more. Let's now come back to the analysis part. Yes, it is possible to do the "whole-world analysis" outside the compiler. But what perspective should the analysis take? It is irrelevant if it cannot reduce the number of possible classes - we don't want all of Java runtime library in there, for example. We need to discover which parts are needed from the code that *could* be executed. GWT determines this based on entry points and other configuration in the *.gwt.xml files *and* what it finds in the compilation classpath, as configured, including its own version of the standard library. So, the pre-compilation analysis tool would have to configured exactly the same and process exactly the same configuration as the GWT compilation step. This would have to evolve in lockstep with GWT. It would also be doing the same processing and analysis that GWT already has to do - at least the step of deciding which bits of code to convert to JavaScript before any further optimization. 

My point is simply if the Java->JS compiler is moving to separate compilation, having hooks in it cannot help you if the things you want require whole-world analysis.  If the reachability analysis is done at a later "linking" stage, then clearly that cannot be available at the compilation stage.

So I think what you want is fundamentally incompatible with the separate compilation direction.  That means that either GWT3 is not for you or you will have to build an external tool that basically does much of what the existing GWT compiler does now to get what you want.

--

John A. Tamplin

[Thomas Broyer]

On Wednesday, May 24, 2017 at 7:14:52 AM UTC+2, Learner Evermore wrote:

... continuing the above - there is more. Let's now come back to the analysis part. Yes, it is possible to do the "whole-world analysis" outside the compiler. But what perspective should the analysis take? It is irrelevant if it cannot reduce the number of possible classes - we don't want all of Java runtime library in there, for example. We need to discover which parts are needed from the code that *could* be executed. GWT determines this based on entry points and other configuration in the *.gwt.xml files *and* what it finds in the compilation classpath, as configured, including its own version of the standard library.

Actually, no.

It indeed does use <source> and <super-source> from gwt.xml files to subset/superset the compilation classpath, but it does *not* take the EntryPoint into consideration; not at that point.

First generators are run and generate code, then only things are optimized.

So a pre-compilation analysis would "only" have to possibly subset the compilation classpath (though ideally you'd separate out what's not "translatable" and just not put it in the classpath at all; actually, afaik, j2cl has a similar "interface" as javac where you explicitly list the files to translate, so that's work that'll have to be done anyway, though GWT 3 might do it for you, keeping the gwt.xml files; this is part of the "we don't know what GWT 3 will look like" bucket).

That being said, if you agree to whitelist classes in annotations on the RemoteService interfaces (similar to the @ExtraTypes of RequestFactory), then this processing step could possibly be an annotation processor rather than a separate pre-processing tool/step.

 

So, the pre-compilation analysis tool would have to configured exactly the same and process exactly the same configuration as the GWT compilation step. This would have to evolve in lockstep with GWT. It would also be doing the same processing and analysis that GWT already has to do - at least the step of deciding which bits of code to convert to JavaScript before any further optimization.

Tooling can help here (you can already do that with GWT 2.x by calling ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might become a good reason to provide a CLI tool producing a list of files or patterns out of a gwt.xml that you could feed to other tools; see however the comment above about "we don't know what GWT 3 will look like")

 

Are we done with that? Whether or not you think that this still can or should be done outside and with no integration with J2CL, let's move on to the debugging. How about *any* dev mode where the code is to be automatically updated on demand? What event signifies that demand? When can we trigger that analysis and code gen step before, say, the Super Dev Mode of the future gets hold of the code? Again, without any ways to hook into that, we'd be relying on the analysis and code generation already having been done by the time SDM has to do anything with it and that means either manual triggering or something like "on save", if that can be monitored (not reliable). And how would that pre-step be configured by the developer? Duplicating configuration but possibly in a different way?

I'd say yes (this is my own opinion, also see "we don't know what GWT 3 will look like" above).

This is not much different from annotation processors actually.

IDEs ("on save" actions), build tools (e.g. Gradle continuous build) or other watchers (watchman, modd, etc.) can help here.

Though if you change any class that's shared with your server, you'd have to redeploy the webapp too (with current DevMode's embedded server, that means clicking the "reload server" button); so possibly that step would better be manually triggered (YMMV)

As said previously, one criticism of Google against the current GWT 2.x architecture is that it "does too much", and part of the j2cl effort is to split things into smaller and simpler tools, replacing some of them by existing tools, and (from Google's point of view) leveraging their build system (that promotes small compilation targets and provides fast incremental builds and continuous rebuilds – the latter is not yet opensourced into Bazel afaict).

One thing that we need to do for GWT 3 is to somehow "package" those separate tools into an easy-to-use product (think polymer-cli and the like), so maybe GWT 3 will introduce its own daemon to monitor source files and trigger some actions before feeding them to the j2cl+closure-compiler toolchain, or maybe not.

[Thomas Broyer]

On Tuesday, May 23, 2017 at 9:57:35 PM UTC+2, Learner Evermore wrote:

J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.

I didn't think much of this when I read this the first time but I just realized that for J2Cl you say "it'll be open source...", meaning it isn't yet... and it is likely the place where the modifications need to be made to, at the very least, expose necessary hooks to make things possible. That makes it impossible for the community to help (before it is open sourced).

Open-sourcing j2cl takes time (see https://opensource.google.com/docs/releasing/ , we've been told it's currently in the "getting approval" phase), more time than for jsinterop-generator or elemental2.

But no work on GWT 3 will happen before j2cl is open sourced (maybe some of us steering-committee members and core contributors will have access to a private repo so we can start thinking about how to build GWT 3 using it; but no open-source work will likely happen before j2cl is itself open source, and this is specifically why we're still in that "we don't know what GWT 3 will look like" situation).

BTW, for now, the only "hook" that has been identified is a way to get access to private fields (others, like Errai CDI, might want access to private constructors and private methods too). This could possibly come in the form of a "contract" in j2cl in the "shape" of the ES6 classes it produces and how it represents private members there; and then possibly using jsinterop-base, or creating a dedicated API based on that contract)

[Learner Evermore]

My point is simply if the Java->JS compiler is moving to separate compilation,

Well, that is why we are having this discussion.

 

having hooks in it cannot help you if the things you want require whole-world analysis. 

It actually can, as I noted above, saving duplication of configuration processing. Otherwise, yes, I could do some global analysis.
 

If the reachability analysis is done at a later "linking" stage, then clearly that cannot be available at the compilation stage.

 Again, that is why we are having this discussion. I need to be able to do reachability analysis together with the code generation ne to have any chance of this performing well. And the problem is that if code gen must happen before J2CL and reachability analysis and optimization later then this can't really be done. Now, I am not saying that J2CL has to do the reachability analysis - but I need to be able to do it at the right time within it.

 

So I think what you want is fundamentally incompatible with the separate compilation direction.  That means that either GWT3 is not for you or you will have to build an external tool that basically does much of what the existing GWT compiler does now to get what you want.

Hence all my comments. Why should GWT3 go into such a direction that it makes it incompatible for me, an existing GWT user, or for any existing GWT user. Sure, it can split things away, but it can allow things to be done externally.

[Learner Evermore]

On Wednesday, May 24, 2017 at 4:06:25 AM UTC-4, Thomas Broyer wrote:

Open-sourcing j2cl takes time (see https://opensource.google.com/docs/releasing/ , we've been told it's currently in the "getting approval" phase), more time than for jsinterop-generator or elemental2.

But no work on GWT 3 will happen before j2cl is open sourced (maybe some of us steering-committee members and core contributors will have access to a private repo so we can start thinking about how to build GWT 3 using it; but no open-source work will likely happen before j2cl is itself open source, and this is specifically why we're still in that "we don't know what GWT 3 will look like" situation).

Yes, I understand and am afraid precisely of all that.

 

BTW, for now, the only "hook" that has been identified is a way to get access to private fields (others, like Errai CDI, might want access to private constructors and private methods too).

At least something but the form of the hook will influence how well things can be done otherwise, see my previous post. 

 

This could possibly come in the form of a "contract" in j2cl in the "shape" of the ES6 classes it produces and how it represents private members there;

and then possibly using jsinterop-base,

That would be (4) from my short list of possibilities. While possible, this is less desirable approach than (2) as per my explanation.

 

or creating a dedicated API based on that contract)

Yes, something like that is what I would like. I am not asking J2CL to perform any analysis including reachability - I must do it. But I need to be able to do it as/when needed. 

 

[Learner Evermore]

On Wednesday, May 24, 2017 at 3:41:13 AM UTC-4, Thomas Broyer wrote:

It indeed does use <source> and <super-source> from gwt.xml files to subset/superset the compilation classpath, but it does *not* take the EntryPoint into consideration; not at that point.

First generators are run and generate code, then only things are optimized.

So a pre-compilation analysis would "only" have to possibly subset the compilation classpath (though ideally you'd separate out what's not "translatable" and just not put it in the classpath at all; actually, afaik, j2cl has a similar "interface" as javac where you explicitly list the files to translate, so that's work that'll have to be done anyway, though GWT 3 might do it for you, keeping the gwt.xml files; this is part of the "we don't know what GWT 3 will look like" bucket).

That being said, if you agree to whitelist classes in annotations on the RemoteService interfaces (similar to the @ExtraTypes of RequestFactory), then this processing step could possibly be an annotation processor rather than a separate pre-processing tool/step.

Well, as I noted earlier... to efficiently generate code and not have to generate it for the whole world, I need to perform reachability analysis before I generate it, which means before J2CL does its thing. Hook would, thus, have to be in the appropriate place. As for whitelisting, the goal is to do at least as good as GWT RPC and better with whitelisting. Specifically, no whitelisting would be needed for the apparent, declared types of classes that are observed communicated. This can be determined with no additional annotations.I can do even better because I can analyze code and see which subtypes of those may be possible as well and include those automatically. Whitelisting comes in addition to that to state possible subtypes from the code that isn't analyzed - e.g. the server code.

Tooling can help here (you can already do that with GWT 2.x by calling ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might become a good reason to provide a CLI tool producing a list of files or patterns out of a gwt.xml that you could feed to other tools; see however the comment above about "we don't know what GWT 3 will look like")

That's GWT 2.x ... I don't know what will survive in GWT 3.0 or in what form. I also don't need any of this in 2.x.

 

IDEs ("on save" actions), build tools (e.g. Gradle continuous build) or other watchers (watchman, modd, etc.) can help here.

Though if you change any class that's shared with your server, you'd have to redeploy the webapp too (with current DevMode's embedded server, that means clicking the "reload server" button); so possibly that step would better be manually triggered (YMMV)

Yes, that is what I noted but I also explained what this does to the experience. Also what will happen if someone clicks to refresh while the code is being regenerated? Not nice.

 

As said previously, one criticism of Google against the current GWT 2.x architecture is that it "does too much", and part of the j2cl effort is to split things into smaller and simpler tools, replacing some of them by existing tools, and (from Google's point of view) leveraging their build system (that promotes small compilation targets and provides fast incremental builds and continuous rebuilds – the latter is not yet opensourced into Bazel afaict).

"Too much" is relative. I agree that it did too much for most, because it always did all. But if something saves you time (via reduced development effort, resulting manually written code size, etc) or is a downright compatibility issue, then it isn't too much. I am not asking it J2CL to do it. I repeat, all I need is the ability to have bits and pieces of what some need (and others think of too much) pluggable into this externally. Some may want to plug in UI binder (I don't), for example. You plug the right pieces you need and you get exactly the right amount of stuff - the Goldilocks zone :)

 

One thing that we need to do for GWT 3 is to somehow "package" those separate tools into an easy-to-use product (think polymer-cli and the like), so maybe GWT 3 will introduce its own daemon to monitor source files and trigger some actions before feeding them to the j2cl+closure-compiler toolchain, or maybe not.

Yes, something like that. 

[James Nelson]

Have not read the whole thread yet, but just wanted to point out a few small things.

First, whole-world compilations and transforms are something I've been working on as a replacement for generator subsystem since I heard it was dying a couple years ago.
I have a toy implementation working with java 8 javac compiler plugins, though it looks like that is going away now that java 9 modules exposes the compiler in a more powerful / official capacity

(I have a commit w/ java 9 support already, btw).

From these experiments, I can conclude that it is possible to get typesafe whole-world analysis out of your standard javac process, and do ...anything you want.

The whole-world part does involve forcing javac to reconsider referenced types, and so will be slower than standard javac...  but it is, indeed possible.

My main use cases were a GWT.create-like replacement; I have a prototype able to slurp up the class literals the same (or better) than stock GWT (I also run a fork of GWT 2.X that does other magic-method-magic),

which can then run replacement rules that generate code (completely different AST, and no TypeOracle just yet, but all things are possible with time).  I didn't bother w/ gwt.xml support yet, as it was just a toy to see if it was possible (it is).

My other main use-case was a new ui-templating library to replace the need for ui binder;

the solution I came up with includes a DSL that generates cross-platform view components for web and javafx... android and ios will likely get a kotlin target someday,

but it could easily be stripped down to something that emits artifacts suitable for webpack et al.

Both of these efforts have prototypes laying around that could be cleaned off if there was significant community interest,

but it's hard to spend lots of time on these things when I've also got a day job and an infant at home :-)

So, while I'm not promising I can magically deliver everything that will go missing overnight, it is possible, and there are other members of the community who are interested.

However, to get production-ready support and testing, this would likely need to be a fulltime effort.

Do ye dissatisfied members of the community think it possible that support contracts for GWT 2.X and porting of features into GWT 3.X would be viable?

While I'm currently happily employed,

I would certainly consider working on fulltime support for these replacements if it could occupy my working hours rather than my scant hours of rest.

If your mission critical applications depend on keeping up to date with latest GWT versions but need older GWT features,

well... somebody has to put in time, and it's not looking likely that it's going to come for free from community members' spare time.

In reality though, existing applications can stay on 2.X for a long time, provided odd compiler bugs get worked out.

While I can find a night here or there to fixup things like sysprops not generating permutations correctly (took about 5 hours work),

I also have my own projects on top of work and GWT community and family, so I'm stretched pretty thin.

PS -> I already maintain an open source fork of GWT which includes support for reflection and arbitrary magic method injection.
I did not even try to get these merged upstream because they move in the opposite direction of GWT (I was going for more magic, and they for less);

my long term game plan is to get my extra bells and whistles pulled into the javac plugin system (with my other prototypes in that area), so I can prefer J2CL as well.

While I will get to this eventually, if there is enough motivation to pay to get to it in a hurry, I think there is enough willing talent to pull off ...whatever we want. :-)

[Learner Evermore]

@James: I am interested and may be able to help if you open source it. However, there are integration issues with respect to GWT 3 noted above, in the rest of the thread. Please do read it when you have time.

[Mark Proctor]

On Monday, May 22, 2017 at 7:55:01 PM UTC+1, stuckagain wrote:

I guess he is going through the same steps like most devs who relied on GWT. I recognise the same reactions I initially had. We also have huge applications build on GWT and we don't like rewriting hings that work.  But sometimes it is a good moment to reflect on the choices that were made. With Java 8 support in place I have the tendency to do things different anyway.

After working iwth JsInterrop and Elemental2 (and the ability to quickly interface with other js based widgets) I noticed that my code is much smaller and maintainable.

Right now I still depend on UiBinder and CellWidgets, but I plan to move too Elemento2 and possibly vaadin grid instead or bootstrap datatable.

Superdevmode is also fine in most cases. Sure sometimes it is a fight to put a breakpoint in the right location, but with pretty mode the mapping between js and java is very readable.

Now I just need a replacement for GWTP with annotation processors. If needed I would even like to help out in getting it done.

Check out Errai. Full annotation driven development with HTML templating (similar to AngularJS and what Singular promised). It provides a modern web app dev experience on top of GWT.

http://erraiframework.org

Mark 

On Mon, 22 May 2017 at 14:32, Paul Stockley <pstoc...@gmail.com> wrote:

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+unsubscribe@googlegroups.com.