Earlier quoted context omitted.
Come on Jeremy, this is so disingenuous. > CoffeeScript semantics are just JavaScript semantics, which means that CoffeeScript can seamlessly use any JavaScript library, and vice versa, without any special effort needing to be made. > The one feature that you might find yourself relying on in a project like Tower.js is easy access to the prototypal inheritance found in CoffeeScript's "class" keyword ... but you can e…
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 ). 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 + c…
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.