> Typescript uses type definitions for 3rd party JS libraries ( http://definitelytyped.org/). Potentially something similar could be done for GWT/Java or even one could leverage the Typescript type definitions to automatically create Java wrappers.
I'm working on a tool that could convert these d.ts files to Java classes annotated with JsInterop. Stay tuned. On Tue, Nov 24, 2015 at 10:28 AM Ümit Seren <[email protected]> wrote: > Regarding the Java wrapper for 3rd party libraries: > Typescript uses type definitions for 3rd party JS libraries ( > http://definitelytyped.org/). Potentially something similar could be done > for GWT/Java or even one could leverage the Typescript type definitions to > automatically create Java wrappers. > > AFAIK the gwt-polymer-elements ( > https://github.com/vaadin/gwt-polymer-elements) wrapper generates the > Java custom element wrappers by leveraging the polymer static analyser ( > https://github.com/Polymer/hydrolysis), so there is no need to generate > those wrappers by hand. > > I am not that concerned regarding the future of GWT. IMHO having a typed > language such as Java (especially as Java8 reduces boilerplate quite a bit) > with a good JsInterop is the way to go. > BTW the new Dart release (1.13) features a new JsInterop system that looks > quite similar to GWT's one and they are also working on a dev_compiler, > that looks a lot like what the J2CL compiler will do (supposed to make it > easier to consume Dart code from JS). > > In the last ChromeDevSummit (https://developer.chrome.com/devsummit), > that took place a couple of days ago, it became clear that Google is > pushing the mobile web quiete a lot by exposing mroe and more native APIs > and providing web-plattform primitives so that mobile web apps can compete > with native apps. > Until now performance and tooling has been much better for native app > development but Google started to tackle the issues from different angles > ranging from a fully type aware Javascript engine (Turbofan) to improved > Dev Tools and new best practices (RAIL, app shell, service worker, etc). > So I think GWT 3.0 (Elemental 2, JsInterop, J2Cl compiler) will be in a > good place to leverage those things (maybe I am to optimistic and > deliberately leaving out the pain of migration). > > > > On Monday, November 16, 2015 at 5:56:20 PM UTC+1, Robert Stone wrote: >> >> >> >> On Monday, 16 November 2015 12:34:51 UTC, Thomas Broyer wrote: >>> >>> >>> >>> 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. >>> >> >> Yes and I agree, but taking this approach doesn't truly isolate the Java >> devs from needing to know JavaScript as GWT/JsInterop is providing a very >> thin wrapper over the JS framework of choice. Someone has to put that >> wrapper in place be it a 3rd party or someone in the team and that someone >> really does have to understand the underlying JS framework. At the end of >> the day, the Java devs will benefit from having more of an understanding of >> JS/HTML than they did in 'pure' GWT days. And again, I'm not saying this is >> a bad thing :) >> >> >>> >>> >>>> 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? >>> >> >> I'm not talking about a re-write here, I'm talking about new projects. >> For new projects, I can't see a compelling reason for picking GWT, if the >> devs are going to have to understand JS to use GWT then it is better to >> invest up front time in getting them familiar enough with JS to use it for >> the whole project. This is the decision we have taken in my organisation. >> >> >>> >>>> 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). >>> >> >> True, but I would be amazed if Google were to start any new projects >> using GWT 3. Everything I heard at GWT Create and everything I have seen >> since has convinced me that they are interested in using J2CL/J2ObjC but >> nothing more than that. >> > -- > 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/432020a6-7b7d-4c94-96c6-a397b59be007%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/432020a6-7b7d-4c94-96c6-a397b59be007%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/CABb_3%3D75Kg3Wxmn_N7srn0TrjU9hTsxJ0XGE7T5g_PaXakVXCA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
