On Thu, May 18, 2017 at 5:20 PM, Learner Evermore < [email protected]> wrote:
> >> >> 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. > 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. > > >> 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. > 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. > 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? > 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. > > 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. > 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. > > >> 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. > 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. > > > >> 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. > > 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. -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 [email protected]. > 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 > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/af96cfa8-778a-467a-af96-2569065a4cea%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7cjT4ZZ5onFzMw95%3DjW3%3DAV1UVDyrL8nLBFhZvE5EueEA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
