> 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 easily have your library expose that as a helper function.
Those two statement contradict each other. People who make libraries for CoffeeScript don't go to the trouble of writing a helper function. This doesn't. Batman.js doesn't.
So to consume this a JavaScript user needs to write (or use an existing) extends function. Not hard, but definitely qualifies as "special effort".
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 + constructor functions, it all just works together ... in a way that fancier class systems built on top of JavaScript do not.
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.
> 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 easily have your library expose that as a helper function.
Those two statement contradict each other. People who make libraries for CoffeeScript don't go to the trouble of writing a helper function. This doesn't. Batman.js doesn't.
So to consume this a JavaScript user needs to write (or use an existing) extends function. Not hard, but definitely qualifies as "special effort".