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.
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.