AFAIK, JsDoc actually is more expressive than TypeScript, for example, TS doesn't currently support union types IIRC, which is critical for expressing real world Javascript libraries. It is also a form of repeating yourself to specify a TS file, because a Javascript programmer writing his library code is not going to document it in two places by creating separate files for everything. That repo is great for TS programmers, but honestly, I don't imagine a high velocity JS project constantly keeping these bindings in sync. Who is going to be responsible for updating the TS interface definitions everytime a release of the underlying JS library is pushed?
We've had the same problem with GWT JSNI wrappers in the past, they get out of sync with the JS library that are mapping to, because the person maintaining the JS library doesn't care. I don't have anything against TS, I'm all for first class typing, but I think a solution in which the person who maintains the JS library themselves is encouraged to add the types is superior, and I don't have a high degree of confidence that JS developers enmasse are going to adopt writing TS definitions. Also, I haven't been following ES6 recently, but as far as I'm aware, there are no plans to add either optional types of documentary types. The way I'd propose building this is just to have a pluggable parser for collecting the type definitions, and so when the compiler sees a given .js input file, it asks the plugins to hand back all of the first class type definitions for that file. The format could be anything, parsing JsDoc, loading TS, WebIDL, or XML files like IntelliJ uses. The JS world is too fragmented probably to have one solution. However I will say this: We are looking at replacing the backend JsAst of the GWT compiler with Closure Compiler in the future, so that we don't need to maintain the JS optimization pipeline (only the Java optimization stages), and so using Closure types as intermediate representation makes a lot of sense. On Thu, Aug 8, 2013 at 2:25 PM, Xavier Mehaut <xavier.meh...@gmail.com>wrote: > I desagree with this assertion ; the goal is not to interop with ts, haxe, > coffee, ..., but only with js. Moreover the future of js is ecmascript 6, > so ts is a good candidate to express properly an interface; this is not the > case IMO of a jsdoc like solution which is verbose and not so precise and > concise as a true language. > > To finish, i recall in mind > https://github.com/borisyankov/DefinitelyTyped > as a reminder of the power of the d.ts technics > > Best regards > Xavier > > Envoyé de mon iPhone > > Le 8 août 2013 à 22:39, Ray Cromwell <cromwell...@google.com> a écrit : > > As cool as I think TS is, there are far more lines of code out there in > Js, some even with JsDoc type assertions, so I think the latter would be > more useful as a first pass. JsDoc is comments so it works with existing > JS. We could explore importing libraries defined in TS, Dart, haXe, et al > via some kind of standard plugin extension. > > > > On Thu, Aug 8, 2013 at 9:08 AM, Brian Slesinsky <skybr...@google.com>wrote: > >> It might be nice to be able to say that anything defined in a .d.ts can >> be imported into GWT. This will make it easier to work with JavaScript >> programmers since they don't have to write any Java code. So perhaps it's >> worth making sure that generating the Java interfaces from .d.ts files will >> work? I know that generating Elemental code from WebKit IDL files wasn't >> easy. >> >> However, our main use case is to import web components which are new. So >> my question is how likely people are to write .d.ts files for web >> components; I don't know if there is much overlap between those two >> communities yet. >> >> >> On Tue, Aug 6, 2013 at 3:02 PM, Goktug Gokdogan <gok...@google.com>wrote: >> >>> Jon (Stalcup) just warned me that it may not necessarily orthogonal so I >>> will make a clarification to what I said. >>> >>> There are number of reasons why it makes we sense to define the contract >>> with java syntax and interface files for GWT (easy IDE support and JDT >>> integration and developer familiarity etc.), but someone might have chosen >>> to start with a custom syntax like the d.ts files. >>> Assuming these interfaces exist and understood by the compiler, any >>> other support can be built on top of that by generating them and provide a >>> seamless integration. >>> >>> >>> On Tue, Aug 6, 2013 at 1:25 PM, Goktug Gokdogan <gok...@google.com>wrote: >>> >>>> We were planning to look into making integration seamless if closure >>>> type annotations exists but that's kind of orthogonal to this proposal. >>>> When we have that integration, it might not be hard to utilize >>>> typescript via typescript to closure conversion. >>>> Thanks for suggestion. >>>> >>>> >>>> On Tue, Aug 6, 2013 at 1:29 AM, Xavier Mehaut >>>> <xavier.meh...@gmail.com>wrote: >>>> >>>>> Hi goktuk >>>>> A nice way to interop with js is the way typescript does through the >>>>> .d.ts files where js api is declared in a typed way, ensuring then the >>>>> ability to interop with any preexisted js. Moreover, already existing >>>>> .d.ts >>>>> files for many js libraries exist on >>>>> https://github.com/borisyankov/DefinitelyTyped >>>>> No extra wirk to do then :) >>>>> >>>>> Best regards >>>>> Xavier >>>>> >>>>> >>>>> Envoyé de mon iPhone >>>>> >>>>> Le 6 août 2013 à 09:24, "Goktug Gokdogan (Google Drive)" < >>>>> gok...@google.com> a écrit : >>>>> >>>>> I've shared an item with you. >>>>> >>>>> >>>>> This is a design doc that describes a proposal for improving >>>>> interoperability with GWT and javascript. The proposal provides some >>>>> essential pieces to provide better and easier interoperability with JS >>>>> while putting more complex scenarios (e.g. Web Components) and >>>>> testability into account. >>>>> >>>>> Please take a look and provide us some feedback. >>>>> >>>>> Cheers, >>>>> >>>>> - Goktug >>>>> >>>>> [image: Document] Nextgen GWT/JS Interop >>>>> (Public)<https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing> >>>>> Google Drive: create, share, and keep all your stuff in one place. [image: >>>>> Logo for Google Drive] <https://drive.google.com> >>>>> >>>>> -- >>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>>>> --- >>>>> 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. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>>> >>>>> -- >>>>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>>>> --- >>>>> 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. >>>>> For more options, visit https://groups.google.com/groups/opt_out. >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> http://groups.google.com/group/Google-Web-Toolkit-Contributors >>> --- >>> 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 >>> . >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- >> http://groups.google.com/group/Google-Web-Toolkit-Contributors >> --- >> 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. >> For more options, visit https://groups.google.com/groups/opt_out. >> >> >> > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > > > > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > 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. > For more options, visit https://groups.google.com/groups/opt_out. > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
