3 ms·

No, I'm actually trying to be completely ingenuous. I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://back

No, I'm actually trying to be completely ingenuous. I agree with you that Tower and Batman.js should both have "extends" functions built-in (*Ahem: http://backbonejs.org/#Model-extend http://backbonejs.org/#Model-extend). It would be a line or two of code for them to add, and make it easier for folks that don't have other library or CS support for setting up prototype chains. The point is that because CS classes are the same thing as JS prototypes + constructor functions, it all just works together ... in a way that fancier class systems built on top of JavaScript do not.

phleet 15y ago
So I agree (for the most part) that using them together is not a problem, but I think there still is some justification for the "unwieldly" argument - which may or may not have been what was discussed at the bootcamp. 1. Some people seem to be under the impression that since they're interoperable, it's fine if half your team is doing raw JavaScript and the other half is using CoffeeScript. At some point, one of the JavaScript authors is going to try to modify the generated JS, which will likely be checked in if there's no asset packaging (I've seen this in practice). 2. The way that people design APIs in CoffeeScript and JavaScript is very different, because the things that are easy in CoffeeScript and easy in JavaScript are different. Namely, CoffeeScript libraries tend to leverage the OO capabilities in a way that makes them ugly to use in raw JS. For example, the `@field "title"` stuff would have to expand in a way that's not particularly obvious or concise. Another example would be trying to use an API like CoffeeKup in JavaScript - the `->` is not visually distracting in CoffeeScript, but having `function() { }` everywhere in the JavaScript code completely destroys the concise nature of the API. In JavaScript, it might be more natural to implement it as an object literal as opposed to nested callbacks.

phleet 15y ago

So I agree (for the most part) that using them together is not a problem, but I think there still is some justification for the "unwieldly" argument - which may or may not have been what was discussed at the bootcamp. 1. Some people seem to be under the impression that since they're interoperable, it's fine if half your team is doing raw JavaScript and the other half is using CoffeeScript. At some point, one of the JavaScript authors is going to try to modify the generated JS, which will likely be checked in if there's no asset packaging (I've seen this in practice). 2. The way that people design APIs in CoffeeScript and JavaScript is very different, because the things that are easy in CoffeeScript and easy in JavaScript are different. Namely, CoffeeScript libraries tend to leverage the OO capabilities in a way that makes them ugly to use in raw JS. For example, the `@field "title"` stuff would have to expand in a way that's not particularly obvious or concise. Another example would be trying to use an API like CoffeeKup in JavaScript - the `->` is not visually distracting in CoffeeScript, but having `function() { }` everywhere in the JavaScript code completely destroys the concise nature of the API. In JavaScript, it might be more natural to implement it as an object literal as opposed to nested callbacks.