> > > 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. -- 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/af96cfa8-778a-467a-af96-2569065a4cea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
