> > > 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.... > > OK, that is almost calming.
> But the Gmail team is 12 years old, we have a vast codebase that includes > a lot of JS... > That is fine. I understand and respect that. > 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. And zero abstraction. If your platform changes the look and feel, your product running inside it won't. As I mentioned before, it isn't just about CSS. It is about behaviour and UX paradigms as well. Widgets are a great abstraction that allows complete separation of concerns. Maybe they don't perform the fastest but that may be more important for games. And even though there was GWT Quake a while ago, it isn't GGT but GWT, with slightly different implications. In any case, my opinion is that both approaches should be possible. We are staying away from direct HTML DOM manipulation and have abstracted wherever possible, with no user-discernible performance difference, yet it allowed us to evolve very quickly and very compatibly. > 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). > > In our apps we are 99.9% Java, with some JS where we had no choice. > 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. > > I understand and appreciate that. But brute force compaction will only get you so far. At some point you come to a situation where this no longer works and you have to split code. And that isn't a bad thing. Users access different area of application at different times, not all of it at once. Having a little code loading as they enter an "area" of the app for the first time isn't so bad. But the approach *can* scale very well. Will there be a small performance hit? Yes, but only the first time they click and only a little. There has to be no (none, zilch, nada, zero) performance difference thereafter, not even a little. > But GWT had three pitfalls: > ... > J2CL addresses all of these... > That is good, I understand, respect and have nothing against that. > > GWT does too much, conceptially it is > ... > We have decided to break this apart into lots of module pieces and replace > what we're duplicating from existing ecosystems > > That too is good. That isn't the problem. > > 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. > Well, there we go. It isn't so much that this "creates incompatibility" as much that it doesn't even begin to allow it in a remotely reasonable way, the way I see ... as you say yourself: > * 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. > 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. Furthermore, how do we make the compiler generate code that accesses private fields? As it is I see only three horrible ways: 1. Preprocess all *.java code and generate new *.java code with synthetic methods, then pass that new code to J2CL. 2. Generate "CL" code that can bypass Java visibility restrictions, hope J2CL doesn't change its code generation style. 3. Make our own J2CL. Again, see TeaVM metaprogramming API Wiki, for example: https://github.com/konsoletyper/teavm/wiki/Metaprogramming for ONE reasonable alternative to this. We may still have to do separate discovery passes, but it it significantly reduces the rest of the work. > > 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. > > Yes, you do handle more users that the rest of us. But that does not mean that your apps are more complex. 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... -- 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/c0e1af1b-1fad-44f6-b414-04f75d525b1e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
