@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. Without it things become essentially impossible for all practical purposes. Getting back to my original question - the business proposition/value let's consider different reasons I can enumerate why people used GWT in the past and what options they would have today: 1. *Just wanted a typed, safe language to work with in the browser.* TypeScript + JavaScript has evolved itself .. and anything below. 2. *Wanted a language in which dangerous undisciplined JavaScript code wasn't possible.* It is always possible but it may be hidden under the rug. TypeScript with some validators, Kotlin and others. If you want Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT. 3. *Wanted Java for sentimental reasons* Java, JSweet, TeaVM, Dragome, Bck2Browser, JavaPoly, ST-JS... are there ... and, yes, GWT. 4. *Wanted all/most of Java RE/VM semantics* Dragome, not sure of Bck2Browser and others. Not GWT - it may have a good chunk of classes emulated but not all of the semantics. 5. *Wanted to share client-side code between web, mobile devices, etc. Not sharing anything with the server. Will abstract the presentation layer "myself". *Kotlin, TeaVM, Dragome, Bck2Browser, ...and, yes, GWT. You will *not* use the HTML abstraction for all the platforms. *All* present platforms, including web/HTML do widgets. Depending on HTML on all is possible but, then again, it really is just a web app... 6. *Same as above, but expecting that the presentation layer abstraction is already present (i.e. not "Swing" approach)* Kotlin? 7. *Sharing code between client and server* This gets to be fun. What code do you want to share? Do you care about what language you run on the server? I am very far from being a fan of node.js but many use it, and it can be used with languages that can translate to JavaScript (e.g. TypeScript and others). If you want Java on the server then what code will you share? If you are only going to share classes that are NOT used for communication (DTOs are excluded here as they are not about code sharing but inherent necessity), then you really can use anything from (4) or (5). If you want to use Java communicate instances of shared classes then you either need to make the communication happen yourself (say via DTOs and 3rd party frameworks) but you become constrained as to what you can and need to do and what libraries you can use - because they need to be compatible in terms of communication. If you don't want to have to worry about this, but only about efficiency of communication and let the framework handle the wire transfers, then there you can use GWT 2.8.1 or older (not 3.0), TeaVM (you have to code a bit but it is possible) and, possibly, Dragome (not sure, but it does reflection too, so it may be possible to add if not already in). I may have missed some solutions out there and haven't listed all those that do apply in all cases but you get the point. Getting the benefit of Closure optimization will be possible with any JavaScript-based solution, including JSweet, TeaVM and possibly others (not Dragome as far as I know). In terms of controlling UI in the web, you can use whatever fills you heart with warmth if you like JavaScript approaches (Angular, React and many others) with almost any of these, perhaps best with JSweet if you want Java. So what are differentiators of GWT? Repating, to an extent, my first post here: - J2CL? Not really. The same can be applied to most other approaches mentioned above. - JSInterop? Not really. Other approaches have other, similar and even better integration (or no need for one). - Presentation control? Matter of taste, but if one wants to get close to the metal, then there are ways to get closer and better. Widget-based approach is easier/safer to work with if one is to share presentation built on top of them between different devices or of, like we do, wants to abstract the foundation's appearance *and* behaviour from the code built downstream from us. Availability of libraries is questionable as all those that depended on GWT widgets go down the drain and have questionable future support. - Size of code? Not really. TeaVM is close and can use the same optimization tool GWT will. - Code splitting? Yes, if it survives, but others aren't far behind. With TeaVM this may be *relatively* a simple endeavour even across synchronous calls and without the "leftovers" issue. - Permutations? Not really. These are not a benefit but a painful means to an end that isn't as needed as before and could be abstracted otherwise? - Serialization, RPC? Non existent. - Compatibility with existing code? No such thing in complex cases. There will be always something you need to rewrite. It may just happen so that, if you take a careful look, using something other than GWT may actually be better. - I18N/L10N resources? We could not live with the number of permutations this creates so we have done thing ourselves, took it away from the permutations system. That shows the benefit of that. - Tooling - i.e. debugging? Others have good, if not better, tools. - Timing? GWT 3.0 does not exist yet. Others do and are, arguably, not sitting still. I am *personally* willing to help but can only do so if there are provisions made to make things at least possible... -- 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/0464a1db-392f-4796-9f19-0de4e9f68fbf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
