On Thu, May 18, 2017 at 9:29 AM Learner Evermore <[email protected]> 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 > > <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. > > 1. > 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. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fDb2vj7F10x8KfzVW%2BxiBC9wX%2B3zW49u5hmHcYrRQcgg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
