On Tuesday, May 23, 2017 at 5:27:44 PM UTC+2, Learner Evermore wrote: > > @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. 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. > 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. > > Wrt debugging: Dragome uses asynchronous websockets to run your code in Java, similar to the legacy DevMode; except that DevMode was careful to be blocking and reentrant. With Dragome, if you set a breakpoint in your Java code, your browser continues to run and process events, which means things can go much differently in debug than in production (particularly as soon as you start using some JS code with its own event handling and/or network requests that doesn't reenter your Java code). If you go back in time when SuperDevMOde was announced to replace DevMode, you'll find many people asking whether Pepper could be used instead of NPAPI, or PNaCl, or WebSockets, etc. and all were dismissed for that single reason that they didn't allow blocking the main thread (by design). Debugging also apparently requires you to put Dragome into your webapp (with possible dependency conflicts) rather than have it live separately. TeaVM apparently has it right, by hooking into the browser debugger, but it then requires a browser extension (one for each browser, as the debugging APIs and protocols aren't portable), and currently only has one for Chrome (actually, maybe Chrome is the only browser exposing a debugger API to extensions, I don't know). This also means you cannot debug a mobile device. So, if those a fast enough (as fast as GWT SuperDevMode, or j2cl which I believe and hope will be even faster) *and* can produce readable JS, then you can get a similar experience to GWT SuperDevMode, though you'll never have sourcemaps has their input is bytecode. So, there are trade-offs everywhere. -- 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/29a882c5-8a91-48e1-ae1a-7cad62f936a0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
