3 ms·

The problem with it as a compilation target in my experience is that interacting with other libraries becomes challenging - the JS ecosystem is now huge, but if

The problem with it as a compilation target in my experience is that interacting with other libraries becomes challenging - the JS ecosystem is now huge, but if you want to use many of those libraries from a wrapping language, it's possible but might present many challenges. Like Typescript definition files. Producing them on a massive libraries is near impossible for a single individual to undertake. I've seen some people try to process them from docstrings, but the result was really kludgey.

WorldMaker 10y ago
I think writing Typescript definitions for a massive library is usually pretty straight forward and I've got a few that I haven't minded writing/helping maintain. "Good enough" typings can be very quick and easy to build and "Perfect" typings take time sometimes but nowhere near "impossible". Furthermore, Typescript recently made it much easier to work with libraries that have no typings at all. If you don't mind implicit anys, things might just work. If you are strict about no implicit anys then the minimum boiler plate to define a module with any type has dropped to a bare minimum: declare module 'module-name' If I have a complaint in that space, it's that sharing typings is a lot more complex than I think it should be. DefinitelyTyped is a single megarepo where most typings originate and has developed a culture of trying to get typings perfect. Unfortunately, perfect is the enemy of the good, and "good enough" typings for lesser used libraries often languish in PR obscurity, at least in my experience. Beyond DefinitelyTyped, libraries can embed their own typings in their npm packages, which is great, but not every library author is thrilled to "own" Typescript typings. (All in all, I still feel like I have better luck contributing typings directly to library authors than DT, though.) Beyond that there are tools like Typings to grab typing files from arbitrary GitHub repos, for instance, but there's not much of a good way to advertise types that way because most people will only check NPM now. Sorry, this seems to have turned into more of an off topic rant than I at first intended.

WorldMaker 10y ago

I think writing Typescript definitions for a massive library is usually pretty straight forward and I've got a few that I haven't minded writing/helping maintain. "Good enough" typings can be very quick and easy to build and "Perfect" typings take time sometimes but nowhere near "impossible". Furthermore, Typescript recently made it much easier to work with libraries that have no typings at all. If you don't mind implicit anys, things might just work. If you are strict about no implicit anys then the minimum boiler plate to define a module with any type has dropped to a bare minimum: declare module 'module-name' If I have a complaint in that space, it's that sharing typings is a lot more complex than I think it should be. DefinitelyTyped is a single megarepo where most typings originate and has developed a culture of trying to get typings perfect. Unfortunately, perfect is the enemy of the good, and "good enough" typings for lesser used libraries often languish in PR obscurity, at least in my experience. Beyond DefinitelyTyped, libraries can embed their own typings in their npm packages, which is great, but not every library author is thrilled to "own" Typescript typings. (All in all, I still feel like I have better luck contributing typings directly to library authors than DT, though.) Beyond that there are tools like Typings to grab typing files from arbitrary GitHub repos, for instance, but there's not much of a good way to advertise types that way because most people will only check NPM now. Sorry, this seems to have turned into more of an off topic rant than I at first intended.