> > 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. >
Well, you are making the same point I am now. I am *NOT* advocating JSweet here, just that GWT does not deliver a better solution *in this aspect* than JSweet ... or TypeScript ... or Kotlin. > 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. > > Quite possibly. But also have a look at here https://www.mirkosertic.de/blog/2014/12/gwt-vs-dragome-vs-teavm-for-game-programming ... Yes, it is rather old now, but it is with GWT 2.7 and TeaVM has involved since then, it seems more so than GWT. > 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. > I am not sure it does 50% worse - that seems an arbitrary number. I do expect GWT to do (a little) better, but a little better is not enough to offset other characteristics where GWT looses badly compared to other approaches. As for readability... transparency of such code is temporary at best, as it may change at any time to accommodate evolution of both languages. That means that it isn't stable and cannot be relied upon. Finally, why would I want to do JS programming at all? The main point is to be able to do as much as possible in a better language and stay away from JS, not more. If I wanted to do JS, I'd do JS... or TypeScript... or JSweet ... or Kotlin... and I do not. I do not want that because it is Java code I can share and it is Java code that defines interfaces between what different teams produce much better than JavaScript and allows better code sharing with the server than other listed alternatives. I don't have a particular need to read Java bytecode, do I? And it works quite well, debugs well and even runs in the browser without plugins (Dragome, TeaVM, Bck2Browser). If I wanted readability, it would not have been JS I'd want it in. Also have a look at JavaPoly.js, ST-JS, ... There are many competing technologies right now. > > >> 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. > > Hacky != allows it. It has to be stable, guaranteed possible. Horribly slow and cumbersome != allows it. GWT is slow as it is. It *can* be made faster but instead of that the path of least resistance is chosen - getting rid of the important features that are hard to implement. Delayed beyond the deadline of having to move on != allows it ... too late. > 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. > > There are two things to realize: (a) this is possible without rocket science and without runtime performance degradation and (b) slight expense of very slightly larger code is perfectly acceptable when the benefit is huge otherwise. Pay a little to get a lot. We have a very large product in which total size of all fragments is about 5M (uncompressed). Initial fragment is presently half that size and is very hard to get smaller. This is our foundation on top of which more modules are built, adding further to code size. Hope was that GWT will evolve as this is perfectly possible to address, but it did not. And, no, this is not a "web site" that needs SEO. This is *meant* to be a "single page app" for a reason. If code is loaded in careful selected coarse units there is very little performance degradation from loading. Leftovers don't need to exist as such, because they would be split as well and not handled the way they are today. > 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. > > I am not underestimating the difficulty of that. I have decades of software development/design/architecture behind me and have made OSes, optimizing compilers, analysis tools, etc. GWT is already doing this, but it is doing it both inefficiently (provable) and it does not store the result of analysis in a way that can be reused by someone else later. But I do feel that the needs of us who develop very large scale apps are underestimated and the importance of such a thing. Right now we are re-running the GWT compiler every time we need to change (usually add) modules. That takes a while and requires us to include some form of all relevant source code even if we didn't want that. Not sure how to "engage with steering committee members" beyond communicating in places like this, as I can find very little information from them too. > 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. > > Thank you for your time and effort. I am just hugely disappointed with the (lack of) attention to GWT and care of existing users of GWT. There are only excuses why not do something, no vision as to what to do beyond the miraculous and mysterious J2CL. -- 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/26d9e6eb-97b4-4434-a477-b1bc0ef5c462%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
