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). -- 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/60906160-eae2-4e47-9009-9904e6491583%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
