On Fri, May 19, 2017 at 5:45 AM, Learner Evermore < learner.everm...@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+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ms > gid/google-web-toolkit-contributors/744d8ab0-d243-4ba3-bce4- > 54ebe48053c3%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/744d8ab0-d243-4ba3-bce4-54ebe48053c3%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7fiAaXWqArAgM0cDaT%2B3tN5ix3aOkfgPt0uBmMHfQNhyw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
