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
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?
Yep, insuring a clear interface between different world is always valuable
and even mandatory in my opinion.. Typescript .d.ts files have already made
the job, so why not using this syntax. As a early adopter of gwt in 2006, i
could also say that I'm an early adopter of typescript on real projects
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
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
I think that's a good point; someone went through the trouble of creating
these definition files so it would be nice to be able to use them, even
without using TypeScript at all. (On the other hand, how many of those
libraries would you say are relevant for GWT? I don't see us using
backbone.)
First of all, as long d.ts works, end user should not care if the compiler
directly understands it or there is a converter in between.
Even the starting point is d.ts or type annotations, in order to have good
IDE support you still need a java representation so that your code will
compile and
I've shared an item with you:
Nextgen GWT/JS Interop (Public)
https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit?usp=sharing
It's not an attachment -- it's stored online. To open this item, just click
the link above.
This is a design doc that describes a
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
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
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
11 matches
Mail list logo
