But the opposite is not always true. There are many libraries written in CoffeeScript that are difficult to use in plain JavaScript due to the use of its class syntax. You can use Underscore.js to get around this, or just write your own inheritance code, but that's obviously a big tradeoff. Of course, using TypeScript libraries in JS will likely have this same issue.
> There are many libraries written in CoffeeScript that are
> difficult to use in plain JavaScript due to the use of
> its class syntax.
No, there aren't. I can only name one, and it's a willful-on-their-part-oversight that could be easily fixed by adding a function like this:
Model.extend = (child) -> child extends Model
...
> You can use Underscore.js to get around this
No, you can't. Underscore.js has nothing to do with inheritance.
> Of course, using TypeScript libraries in JS will likely
> have this same issue.
Yep -- TypeScript implements a very similar inheritance function, and the potential workaround for subclassing TypeScript constructors from JavaScript should be equally easy.
The need for workarounds makes fragmentation an inevitability. That's not a reason for to-JS languages not to exist; every developer should make the decision on what works for their own needs, but ignoring it is foolish.
there are many libraries written in JavaScript that are difficult to use in plain JavaScript due to the use of a classy syntax, that's why even halfway decent developers care about displaying clean interfaces / API endpoints.
Developers targeting the JavaScript community will be careful to have good API endpoints, but not all to-JS programmers care about that. Batman.js (http://batmanjs.org/) is one example that doesn't.
Comments
But the opposite is not always true. There are many libraries written in CoffeeScript that are difficult to use in plain JavaScript due to the use of its class syntax. You can use Underscore.js to get around this, or just write your own inheritance code, but that's obviously a big tradeoff. Of course, using TypeScript libraries in JS will likely have this same issue.
The need for workarounds makes fragmentation an inevitability. That's not a reason for to-JS languages not to exist; every developer should make the decision on what works for their own needs, but ignoring it is foolish.
there are many libraries written in JavaScript that are difficult to use in plain JavaScript due to the use of a classy syntax, that's why even halfway decent developers care about displaying clean interfaces / API endpoints.
Developers targeting the JavaScript community will be careful to have good API endpoints, but not all to-JS programmers care about that. Batman.js (http://batmanjs.org/) is one example that doesn't.