On Monday, November 16, 2015 at 11:29:14 AM UTC+1, Robert Stone wrote: > > > > On Sunday, 15 November 2015 15:37:29 UTC, Stephen Haberman wrote: >> >> >> My worry about "just pick a mainstream JS framework and use it via >> JSInterop" is that if you're a) coupled to a JS environment for unit >> testing and b) interfacing with a framework that is inherently >> dynamic/untyped, what's the benefit of using GWT in the first place? >> > > > And this for me sums up GWTs main issues going forward. The benefit before > was that existing Java devs could use GWT to work on all the layers of an > application. GWT 3 will force (not a bad thing) Java devs to use JavaScript > for their views and will also force them to deal with integrating JS and > Java code. >
I think Vaadin and Julien Dramaix showed during the last months how you can use GWT to create Web Components (through Polymer), so no J2CL or GWT 3 won't "force Java devs to use JavaScript for their views". As for "forc[ing] them to deal with integrating JS and Java code", it shouldn't be much different from the current situation dealing with Element and NativeEvent (com.google.gwt.dom.*), Storage, Geolocation, etc. and Elemental 2 (to be released shortly after 2.8 AFAIK) should help bridging this gap. > At this point, you have to ask 'Why bother with Java/GWT at all' - switch > the full application to pure JS. > If you have the luxury to "switch the full application" to another stack (i.e. "big rewrite") *and* you have devs whose JS skills are comparable to their (or the other team's) Java skills, then why not? > For existing large projects, switching to GWT 3 is almost a non-starter as > there will be far too much existing view code to convert over so they will > have to stick with the GWT 2 stream and hope that it remains well > supported. This is the situation my company face with one of our products. > > So GWT 3 is not ideal for new projects and doesn't help with existing > projects. Where is it's market? > I think Google is increasingly building "hybrid apps" where they want/need to share "business code" between several platforms rather than rewrite the same thing in 3 languages: server, web client, android, and iOS. Server and Android can be coded right in Java, GWT will bring the shared Java code to the web client (where the UI could be written in JS, as is the case for “Inbox by Gmail” or Google Spreadsheets), and J2ObjC will bring that code to iOS (that's actually exactly the pitch in the J2ObjC homepage introduction: http://j2objc.org/). So GWT becomes more about "sharing/integrating Java with JS" than "using Java instead of JS". But keep in mind that there still are apps at Google that use widgets (Google Groups, where I'm writing this, to begin with), and Google likely won't maintain J2CL and the GWT compiler in parallel (at least not for long) so they'll have to find a migration path for their apps: either rewrite their UI in JS (Closure), or make widgets J2CL-compatible, or something in between (rewrite the UI without widgets, but still in Java, using Web Components or some new widgets library). -- 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/0f2827a3-1b56-4b24-9afc-0949550e9497%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
