- For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
- For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly.
- In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries...
- Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work.
- Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package.
- If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
- Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules.
- Deferred binding and code generators are something we do not use directly as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too.
- JSNI methods in comments were nice but are the only thing that truly requires the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni
- Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective). We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new.
For more options, visit https://groups.google.com/d/optout.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 google-web-toolkit-contributors+unsubscribe@googlegroups.com.
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.
I'm not sure I understand. If you use JSweet, it is very likely to break on using libraries from the Java ecosystem, which breaks a huge value proposition of using Java in the first place. It doesn't even support static field initialization and class initializers with proper semantics last time I checked. Someone who has learned Java will be very surprised at weird failures in the pipeline. GWT has parts of the JRE it doesn't support, but from a language level, it passes most of the JLS spec with some exceptions around numerics, overflow checks. My advice is, if you need a language with types and good IDE support that maps to JS, use TypeScript or Kotlin. Kotlin every has a great Java interop/JVM ecosystem story and amazing IDE support.
I just checked the demos on Github, TeaVM's box2d demo loads 306kb of JS (when uncompressed). WebAssembly version is ~500kb uncompressed. The GWT version is 148kb uncompressed. The J2CL Box2D demo we use internally, while not strictly an apples-to-apples comparison, is 35kb uncompressed.
Yes, it's a whole program optimizer, but it's about 50% worse than GWT at pruning, and a lot worse than J2CL + Closure Compiler and it doesn't support code splitting. Why should one care about readability? Because besides source maps, it makes it much more transparent what's going on AND it integrates with the rest of the ES6 module system very easily. Every Java file can become a ES6 module, and any JS file can simple require/import it as if it was any other hand-written JS. This makes it very easy for JS programmers to work with it (Inbox.google.com is 60% Java, 40% JS). It makes Java more of a natural, first class member of a JS ecosystem. If you like JSweet, this does the same thing, only much better.
Community can only do it if the foundation allows it.The foundation allows it, but it's hacky. I showed how it could be done. You can use a Generator + Linker combo to get async/await annotations in the output, and then invoke BabelJS from the linker to transpile the ES7 async/await calls back into ES5.
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.Yes, any call can be come a split point, and we do that at Google on projects like photos.google.com, where every controller, every event handler, every widget, or every data request is a split point. But GWT doesn't support this, someone needs to significantly improve the CodeSplitter in GWT to make this worthwhile, otherwise, it will made total code size loaded in the first split point triggered worse.
I've presented ideas on this before at GWT gatherings (server side linking), but I think you're underestimating the difficulty of making this work, and making it work at scale. I encourage you, if you have a workable design, to engage with steering committee members to see if anyone is interested in implementing it.
These are all issues the Steering Committee members can take up, I'm not a member of the SC any more, these are just my opinions.
Can somebody please tell us who are the members of gwt committee
and is there any meeting notes in the last year (or two) ?
Hi there!I am faced with having to re-think what we are doing in the company I work for with respect to GWT, existing and new projects and I am struggling, to say the least. We've been very much a GWT shop for years now and have used it to expedite the development of very large solutions and improve the end user experience. We did this and this was possible because:
- There is (was?) a visible big name behind the technology - Google. There were regular updates and a lively community.
- It allowed us to share a lot of code between the client and the server properly and use a programming language suitable for very large software - strong typing, encapsulation/visibility control and all the works. JavaScript just isn't an option - it isn;t even a thought with all the enhancements they are making.
- It allowed us to cleanly and efficiently segregate and encapsulate functional responsibilities of both business and representation code. We were able to create a foundation with clean APIs that other teams build their modules on top - and we bring those modules together. We can evolve that foundation and dramatically change it looks beyond just CSS because we encapsulated units of UI into widgets and we came up with the means to aggregate client-server communication from all modules into single requests/responses via serialization (we otherwise used GWT RPC very little - there is a single service with a single method in there).
- It offered integrated code optimization and debugging tools with what seemed to be a promising future vision and dedication.
We've been following what is going on with GWT 3.0 and, admittedly, didn't like it. However, we were hoping that our problems are common and that it will become apparent that GWT 3.0 vision needs some adjustments. We've observed other people communicating similar perspectives to ours. Unfortunately, we've also seen little acceptance of these comments, little action and, essentially, no direction with respect to those beyond "waiting to see what happens with GWT 3.0". We believe that this effective limbo is, at least, a big part of the reason for frequent statements like "GWT is dead, past its time" and abandoning the technology simple because they have to move forward but are left behind.I/we perfectly understand the reasons why one would want to do things planned for GWT 3.0. Removals of GWT RPC and widgets can simplify some code and increase the performance of the tools, among other things. At the same time, I believe that the perspective taken to decide what to do is wrong. Instead of finding ways to simplify GWT at the expense of making GWT-based products more complex and loosing any chance of being compatible with pre-3.0 code, efforts should have been focused on solving the problems.
I know that these problems are hard, but they are also possible to solve. I know because I made solutions to similar problems. Yes, new GWT may produce code faster and it may produce faster code and it may interoperate better with the browser and JavaScript. But consider the following:
- For perfect interoperability with JavaScript one can use JavaScript or TypeScript. Or, if you like Java (syntax), use JSweet or TeaVM.
- For sharing code with the server, some people use node.js (I do not subscribe to this) but there are other options - JSweet, TeaVM, possibly Dragome and others.
- For runtime performance of the code written in Java (via optimizations and otherwise), TeaVM seems to yield better performance than GWT with JavaScript output and also has experimental support for WebAssembly, which yields about double the performance on some tests I've seen. One could offer both options, to support browsers that can't do WebAssembly.
- If one is forced to use external frameworks for serialization they don't get any benefits from GWT that other alternatives don't also get.
- In terms of tooling - GWT seems to, now, be the worst. Super Dev Mode proved to be essentially a failure because one does not really see the data that matches the code. Runtime performance still suffers and debugger often freezes for long periods of time doing who-knows-what if/when breakpoints are set or we're stepping through code. Coding in JavaScript directly means what-you-see-is-what you get and no wait times. Other solutions offer their custom tooling which seem to be possibly better, at least on paper (did not check, so cannot verify yet). JSweet and TeaVM translation is much faster than GWT is, even without GWT RPC. TeaVM does not require source code, which is better for companies who need to deliver a module but keep the source closed. GWT needs *both* source and binaries...
- If we're to work directly with the metal, similar to how JavaScript frameworks do things, then again - JSweet may be a better fit, possibly TeaVM. Neither has widgets in a sense GWT does/did.
Put it simply, GWT 3.0 does not seem offer a path for existing users,
does not have much novel for brand new users that isn't already available othewise and better, takes more time to do whatever it does and slows down the development and is losing trustworthiness - what guarantees that, if I start with GWT 3, I won't be left stranded when GWT 4 comes out... if it ever will?
So, who is GWT 3.0 for? Who will use it?
Does this mean that there really is no vision about how GWT can truly evolve and grow? If so, let me offer some of my challenges that would be best solved or need to be solved in GWT, in no particular order.
- Simulate synchronicity even for what would be, under the hood, asynchronous calls. See TeaVM for how multithreading is supported in it, Thread.yield() and related. We know why things must be asynchronous in JavaScript, but that does not mean that this has to be exposed as such in the Java world - a Java method could "block" at a call only to continue when a relevant event is triggered. This would go a long way to simplifying the code and increasing how much code can be shared between the client and the server without exposing the server to unnecessary asynchronicity or the client with synchronous methods that may/will not work.
- Doing the above will let you improve code splitting as you will be able to load code at any point, not just at GWT.runAsync() points. It will open up other possibilities of driving how the code is split - e.g. perhaps per module, project or package.
- Separate widgets into an optional module but definitely keep them going. They are important. They are used, both directly and via 3rd party libraries.
- If you are so hung up on removing GWT RPC, do so, but provide the means to replace all of its functionality externally, especially serialization. This is possible in TeaVM with its "Metaprogramming API". Arguments that "it is hard" are not helpful and "I don't need it" may apply to a class of users who really don't need GWT at all or are not creating very large scale products. Keep in mind - GWT RPC is *NOT* about APIs but allowing matching OWN client and server code to communicate. Do include the means to store discovered relationships so that they don't have to be discovered again. Allow polymorphic serialization one way or another via specific annotations. Whether done internally or externally, rethink RPC with respect to (1) - synchronicity emulation and what plumbing code needs to be written. There is a discussion about these things in https://groups.google.com/forum/#!msg/google-web-toolkit/34viZIdAjBQ/EPhzKi9iCgAJ
- Bring back (something like) *.gwtar files. Even better, replace them with something that will be self-sufficient and *not* have the original source code in it. This would be very useful for both increasing the compilation performance and for delivering closed-source modules.
- Deferred binding and code generators are something we do not use directly as we tried to be as "clean" as possible. As I am propagating compatibility, you should not remove this but do provide means to not depend on it. That may have a significant performance impact too.
- JSNI methods in comments were nice but are the only thing that truly requires the source code. Find other ways of doing this, such as via annotations or separate files, e.g. for each Foo.java there may be Foo.jsni
- Think about how would one support post-development (e.g. install-time or run-time) linking of multiple modules. For example, we build our foundation product, but our partners build plugins for it. Customer chooses and installs plugins they want. Right now this forces us to do a GWT compilation step at that time and it is painfully long. (from the customer perspective). We are trying to hide this cost in various ways (store results, reuse them across nodes, etc.) but I am sure you can figure out the challenges. Since these modules only communicate via dedicated APIs, obfuscation can be limited to the implementation only and/or there can be an overlay of "exported" symbol maps for cross-module calls. This is a very similar "problem" to Java class file obfuscation so nothing new.
- Clean up the tooling. Stop embedding everything in a single monolithic jar, update code coverage tool support. Rethink debugging - perhaps leverage existing work done outside GWT for this? Separate the classpath of the compiler from what it is supposed to compile. These are not the same thing and cause grief.
Without the above, what seems to be a closer alternative to existing GWT 2.x users is a separate fork of GWT (that may not be coming any time soon) or a TeaVM enriched with a fork of GWT widgets and a module doing GWT RPC (possible!). It does not have code splitting support (yet) and, likely, no desire (or need) for "permutations" and related concepts. That would require widget libraries to be rewritten with that in mind, but that would be possible and would, it seems, yield a better dev environment with a better performing end result.I don't want to see GWT fail. We have our future depending on it and, if we can't use it, I presently don't know what we can do. But we cannot use GWT 3.0. Remember - "I don't need it" is not the same as "Nobody needs it" and "shouldn't need it" is a matter of perspective typically uttered by those who don't create projects as complex as many of us others do.
It would be really nice to see some new answers on this kind of questions from GWT contributors other than: "We don't know how GWT3 will look like in this moment but we know that J2CL will not include this and that" because this sentence is almost 2 years old.
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.
Google's Closure is effectively saying "Closure is "better" than GWT".
Other technologies that are already available may also be better for focused needs - some of which I mentioned in my posts above. Coupled with the steering committee composition, it paints a very bleak picture of GWT 3 future, if any, ever.I will say that the appeal of GWT wasn't writing Java in the browser. That was only a part of it (and most of the complexity). It is about being able to share a lot of code between the client and the server with all the magic in between handled. No other existing solution handles that, including the GWT 3 with any RPC replacement addons. Why? Because it requires writing a ton of boilerplate code and annotations to turn one set of objects into another and back and does not allow reusability.
Google didn't have any incentive to release GWT 10 years ago, or to continue maintaining it in the open source. They've always been the main drivers and main contributors so they could have stopped sync'ing their internal repository to the outside work long ago; but they did just the opposite 4 years ago, with the opensource repository being the source of truth and them sync'ing it into their internal repository (they have a few internal patches, such as completely removing the legacy devmode).You're just being pessimistic here.
RedHat publishes the Errai framework, and has several tools built using GWT (including their JBoss/Wildfly admin console if I'm not mistaken)RedCurrent is actively using GWT (no idea how and where), and employs (at least) 2 of the most productive contributors.ArcBees (which you didn't cite) maintains the GWT-P framework.There once was representatives from Sencha (Colin, then Justin), but they're apparently putting an halt to GXT (no new development at least), and the representatives have left the company.
The Closure Compiler is doing a better job at optimizing JavaScript. Even if it were doing a slightly worse job, using it means freeing development resources to work on something else.Closure is only a part of the whole (future) toolchain though.
Why would it necessarily require a ton of boilerplate code?Also, "handing all the magic in between" makes it way too easy to produce inefficient code in terms of network usage.
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.
--
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+unsu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/744d8ab0-d243-4ba3-bce4-54ebe48053c3%40googlegroups.com.
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....
But the Gmail team is 12 years old, we have a vast codebase that includes a lot of JS...
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:
...
J2CL addresses all of these...
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
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.
* 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.
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.
We looked at this and it seems reasonably simple to get the Widgets
working under a pure jsinterop+System.getProperty world. Simple but
labour intensive. You could do it now if you wanted to prepare for
GWT3.
We use UIBinder extensively and that is probably easy enough to get
95% converted to APT. However I do recall there being a bunch of
scenarios where it becomes harder - although what they were slips my
mind atm. In that case we are likely to just implement the subset and
generate errors if there is any of those scenarios in our code.
I have no idea what shape the client bundles would end up in but I
suspect we would move to using wrappers for whatever tool bundled the
javascript be it webpack or closure (does it have a bundling tool?) or
whatever. I love some of the css-in-js stuff happening in javascript
land - (See https://markdalgleish.github.io/presentation-a-unified-styling-language
for an overview). I certainly see some significant advantages about
changing the way we do stuff here.
> How to reasonably accomplish GWT RPC serialization (all of it)?
It is unfortunate that you have used this feature but I can't see it
ever being implemented by google or the community at large.
Most frameworks based on language/framework specific serialization
strategies tend to fail, often due to the difficulty of interacting
from other platforms or difficult evolving code on the same platform.
Java RMI is largely unused these days. Maybe now is the time to move
to something different*.
... and before someone mentions version/compatibility issues with serialization (using any framework) not that NO framework solves this, they just have different ways of not solving it. And all frameworks expose *exactly* equal ways of dealing with it should one be interested. Including java.io.Serializable. And if you happen to not care and change things, it always results in errors (default cases excepted) only with java.io.Serializable you get that error immediately and with some other popular frameworks you get the error at the time of first use - hence less detectable.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/1eaced67-96f6-4ea0-9ef7-5bbabb2cf569%40googlegroups.com.
As a heavy user of GWT-RPC in a large app, I've become disillusioned with it. That's for three reasons:
- I often need to see what data is being sent, and it's just not very good for that. It makes debugging harder than it could be.
- it's not good for communicating from a mobile app.
- it's much too easy to accidentally send much more data than necessary. Being forced to think about your content on-the-wire would probably make a better product in the long run.
So we're going to pay the price to migrate away from GWT-RPC and I don't feel too bad about it going away.
I just hope we don't have to give up widgets too. I don't see that being practical for us.
I have to agree. A long time ago we moved away from GWT RPC to an approach that used straight JSON. This forced on us by the poor performance on mobile devices. Right away we saw 3 to 5x speed improvement and significant code size reduction. Sure the developer experience wasn't quite as nice. However we, could hardly measure an actual hit in overall productivity. To be honest, our user experience will always take priority over developer UX.
I am really interested to hear how you can make a version of GWT RPC as fast as a pure JSON approach. We take a tree of thousands of objects and just use one JSON.parse / JSON.stringify call to deserialize / serialize which happens within the browser in C++ code. No other processing is required. We use Overlay types to access the data and that is it. In the future we will switch to JsInteop types instead of overlays, that way we only have one version of our DTO's that are used on the client / server.
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.
* 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?
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:
- How to reasonably accomplish compatibility with existing code dependent on widgets (for example Sencha GXT - most should be aware of that)
- 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...
"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.
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
Btw, I'd really like it if for development only j2cl was needed, without the closure-compiler pass (now that most browsers support ...
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.
You are putting words in my mouth. Try reading my comment again. All I said was the approach we took was a lot faster and resulted in smaller code size, both of which are true.
I would suggest you gather up support from everyone who still wants RPC and start planning to build an alternative. It sounds like you have lots of ideas how to make a better version. Talk is cheap, why not make something happen.
--
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-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/81724bf2-552d-4461-9f92-b6fc388f4840%40googlegroups.com.
But sometimes it is a good moment to reflect on the choices that were made. With Java 8 support in place I have the tendency to do things different anyway.
@Anders Forsell: We were careful to make a good separation between UI concerns in Java from the very beginning. We were very strict about this. So, a "forced opportunity" to redo this isn't a benefit to us.Otherwise... if community is to help and roll up the sleeves we still need some things in the core of GWT.
Just because it wasn't mentioned yet in this thread, and I think it deserves some clarification: "the community" does not necessarily mean "third party projects on top of GWT"; GWT is open source and contributions are welcome.
So, there are trade-offs everywhere.
J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.
J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.I didn't think much of this when I read this the first time but I just realized that for J2Cl you say "it'll be open source...", meaning it isn't yet... and it is likely the place where the modifications need to be made to, at the very least, expose necessary hooks to make things possible. That makes it impossible for the community to help (before it is open sourced).
Yes, the GWT/J2CL Google dev team is a bit behind, or maybe everyone (including GWT team at Google) were a bit too optimistic. But I am 100% sure J2CL will be released and open-sourced soon. And from descriptions about J2CL we have seen so far, it does sound like the right minimal approach.
Having said that my prediction is that GWT 3.0 plans will be quickly abandoned once the community gets its teeth into J2CL.
One last point: I, many other GWTers and Google don't care about UI binders, RPC, bundled Jetty servers and other failed ideas (GWT RPC=Java RMI=cute, but bad idea long term) and will be unhappy if such legacy baggage gets tucked into future releases of a J2CL-based product. That leaves the fraction in the GWT community that has vested interest in the legacy stuff to figure out way forward.
And again, I for one, am not calling for GWT RPC to be resurrected in 3.0. I don't need it. But I do need the complete serialization instead of the half-baked, mostly-incapable external frameworks needing-a-ton-of-extra-code-and-still-can't-do-it in existence today. And I can even code that to work much faster than GWT RPC did (I do stuff like that all the time) but it isn't possible without dedicated hooks within J2CL.
Why is that so? Can't you do your own whole-world analysis pass independently of the compiler if that is what you want to do? It does not seem possible to have whole-world analysis in the compiler (hooks or not) if the goal is to enable separate compilation at the Java layer. So, if that is important to you, it must necessarily be outside the compiler.
... continuing the above - there is more. Let's now come back to the analysis part. Yes, it is possible to do the "whole-world analysis" outside the compiler. But what perspective should the analysis take? It is irrelevant if it cannot reduce the number of possible classes - we don't want all of Java runtime library in there, for example. We need to discover which parts are needed from the code that *could* be executed. GWT determines this based on entry points and other configuration in the *.gwt.xml files *and* what it finds in the compilation classpath, as configured, including its own version of the standard library. So, the pre-compilation analysis tool would have to configured exactly the same and process exactly the same configuration as the GWT compilation step. This would have to evolve in lockstep with GWT. It would also be doing the same processing and analysis that GWT already has to do - at least the step of deciding which bits of code to convert to JavaScript before any further optimization.
... continuing the above - there is more. Let's now come back to the analysis part. Yes, it is possible to do the "whole-world analysis" outside the compiler. But what perspective should the analysis take? It is irrelevant if it cannot reduce the number of possible classes - we don't want all of Java runtime library in there, for example. We need to discover which parts are needed from the code that *could* be executed. GWT determines this based on entry points and other configuration in the *.gwt.xml files *and* what it finds in the compilation classpath, as configured, including its own version of the standard library.
So, the pre-compilation analysis tool would have to configured exactly the same and process exactly the same configuration as the GWT compilation step. This would have to evolve in lockstep with GWT. It would also be doing the same processing and analysis that GWT already has to do - at least the step of deciding which bits of code to convert to JavaScript before any further optimization.
Are we done with that? Whether or not you think that this still can or should be done outside and with no integration with J2CL, let's move on to the debugging. How about *any* dev mode where the code is to be automatically updated on demand? What event signifies that demand? When can we trigger that analysis and code gen step before, say, the Super Dev Mode of the future gets hold of the code? Again, without any ways to hook into that, we'd be relying on the analysis and code generation already having been done by the time SDM has to do anything with it and that means either manual triggering or something like "on save", if that can be monitored (not reliable). And how would that pre-step be configured by the developer? Duplicating configuration but possibly in a different way?
J2Cl will be a Google project (not a GWT project; actually not dissimilar to how GWT currently leverages Eclipse JDT/ECJ, Jetty, etc.) but it'll be open source and accept external contributions too.I didn't think much of this when I read this the first time but I just realized that for J2Cl you say "it'll be open source...", meaning it isn't yet... and it is likely the place where the modifications need to be made to, at the very least, expose necessary hooks to make things possible. That makes it impossible for the community to help (before it is open sourced).
My point is simply if the Java->JS compiler is moving to separate compilation,
having hooks in it cannot help you if the things you want require whole-world analysis.
If the reachability analysis is done at a later "linking" stage, then clearly that cannot be available at the compilation stage.
So I think what you want is fundamentally incompatible with the separate compilation direction. That means that either GWT3 is not for you or you will have to build an external tool that basically does much of what the existing GWT compiler does now to get what you want.
Open-sourcing j2cl takes time (see https://opensource.google.com/docs/releasing/ , we've been told it's currently in the "getting approval" phase), more time than for jsinterop-generator or elemental2.But no work on GWT 3 will happen before j2cl is open sourced (maybe some of us steering-committee members and core contributors will have access to a private repo so we can start thinking about how to build GWT 3 using it; but no open-source work will likely happen before j2cl is itself open source, and this is specifically why we're still in that "we don't know what GWT 3 will look like" situation).
BTW, for now, the only "hook" that has been identified is a way to get access to private fields (others, like Errai CDI, might want access to private constructors and private methods too).
This could possibly come in the form of a "contract" in j2cl in the "shape" of the ES6 classes it produces and how it represents private members there;
and then possibly using jsinterop-base,
or creating a dedicated API based on that contract)
It indeed does use <source> and <super-source> from gwt.xml files to subset/superset the compilation classpath, but it does *not* take the EntryPoint into consideration; not at that point.First generators are run and generate code, then only things are optimized.So a pre-compilation analysis would "only" have to possibly subset the compilation classpath (though ideally you'd separate out what's not "translatable" and just not put it in the classpath at all; actually, afaik, j2cl has a similar "interface" as javac where you explicitly list the files to translate, so that's work that'll have to be done anyway, though GWT 3 might do it for you, keeping the gwt.xml files; this is part of the "we don't know what GWT 3 will look like" bucket).That being said, if you agree to whitelist classes in annotations on the RemoteService interfaces (similar to the @ExtraTypes of RequestFactory), then this processing step could possibly be an annotation processor rather than a separate pre-processing tool/step.
Tooling can help here (you can already do that with GWT 2.x by calling ModuleDefLoader/ModuleDef in your code; and those kind of use-cases might become a good reason to provide a CLI tool producing a list of files or patterns out of a gwt.xml that you could feed to other tools; see however the comment above about "we don't know what GWT 3 will look like")
IDEs ("on save" actions), build tools (e.g. Gradle continuous build) or other watchers (watchman, modd, etc.) can help here.Though if you change any class that's shared with your server, you'd have to redeploy the webapp too (with current DevMode's embedded server, that means clicking the "reload server" button); so possibly that step would better be manually triggered (YMMV)
As said previously, one criticism of Google against the current GWT 2.x architecture is that it "does too much", and part of the j2cl effort is to split things into smaller and simpler tools, replacing some of them by existing tools, and (from Google's point of view) leveraging their build system (that promotes small compilation targets and provides fast incremental builds and continuous rebuilds – the latter is not yet opensourced into Bazel afaict).
One thing that we need to do for GWT 3 is to somehow "package" those separate tools into an easy-to-use product (think polymer-cli and the like), so maybe GWT 3 will introduce its own daemon to monitor source files and trigger some actions before feeding them to the j2cl+closure-compiler toolchain, or maybe not.
I guess he is going through the same steps like most devs who relied on GWT. I recognise the same reactions I initially had. We also have huge applications build on GWT and we don't like rewriting hings that work. But sometimes it is a good moment to reflect on the choices that were made. With Java 8 support in place I have the tendency to do things different anyway.After working iwth JsInterrop and Elemental2 (and the ability to quickly interface with other js based widgets) I noticed that my code is much smaller and maintainable.Right now I still depend on UiBinder and CellWidgets, but I plan to move too Elemento2 and possibly vaadin grid instead or bootstrap datatable.Superdevmode is also fine in most cases. Sure sometimes it is a fight to put a breakpoint in the right location, but with pretty mode the mapping between js and java is very readable.Now I just need a replacement for GWTP with annotation processors. If needed I would even like to help out in getting it done.
On Mon, 22 May 2017 at 14:32, Paul Stockley <pstoc...@gmail.com> wrote:
You are putting words in my mouth. Try reading my comment again. All I said was the approach we took was a lot faster and resulted in smaller code size, both of which are true. I said it came with some compromise, which for our use case and I suspect many others isn't a big deal. However, it also comes with other benefits. For example, we can easily communicate with non-java backends and services using the same JSON based approach.It sounds like your use case isn't applicable to this approach. Google have made it pretty clear they don't want to use or support GWT RPC anymore. To be honest they are totally in their right to do this. This is one of the most one sided open source projects I have seen. Virtually all the work has been done by google over the years. Over the last few years all I have seen is people complain that their use cases (RPC, UiBinder, etc) are being abandoned. Now is the time to step up as a community and actually start contributing back. Our company relies on base widgets, UiBinder and Resources. If google doesn't offer these going forward, we will help to come up with alternatives that will work with J2CL.I would suggest you gather up support from everyone who still wants RPC and start planning to build an alternative. It sounds like you have lots of ideas how to make a better version. Talk is cheap, why not make something happen.--
On Sunday, May 21, 2017 at 9:03:55 AM UTC-4, Learner Evermore wrote:
On Sunday, May 21, 2017 at 7:04:19 AM UTC-4, Paul Stockley wrote:I am really interested to hear how you can make a version of GWT RPC as fast as a pure JSON approach. We take a tree of thousands of objects and just use one JSON.parse / JSON.stringify call to deserialize / serialize which happens within the browser in C++ code. No other processing is required. We use Overlay types to access the data and that is it. In the future we will switch to JsInteop types instead of overlays, that way we only have one version of our DTO's that are used on the client / server.As I suspected, you are comparing apples to oranges...
- You made dumb DTOs for this which means that you have to have the code that copies data into them specifically for this purpose. And while DTOs have followers for some cases they are downright antipatterns in other cases. But we don't need to discuss that.
- You either don't have/use polymorphism or have had to code around that as well.
- Any logic you have has to be either outside of the overlay types or not polymorphic and you need to deal with that too.
- You also probably excluded the cost of delayed type conversion.
- How are you communicating long/Long? There are other examples.
- You can't include data of a third party library unless you have the means to make full copies of it and keep in sync with that.
- Enjoy communicating cyclic graphs?
Then we come to the point of how much work you spend addressing the above, esp. for complex types. We don't have to spend any of that. None. Zilch. Nada. We have spent that time ensuring that we never have to send so many objects even if we have to show millions (literally) and made our product better overall.
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+unsubscribe@googlegroups.com.