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.

Reply via email to