我是CoffeeScript的新手，我正在尝试了解管理和构建将在浏览器中运行的复杂应用程序的最佳方式。所以，我试图确定构建代码并构建代码的最佳方法是什么;考虑范围，测试，可扩展性，清晰度和性能问题。
这里建议的一个简单的解决方案（https://github.com/jashkenas/coffee-script/wiki/%5BHowTo%5D-Compiling-and-Setting-Up-Build-Tools）似乎维护了所有文件/单独的类 - 并使用Cakefile将所有文件连接到一个咖啡文件并编译。在确保所有内容都在同一范围内时，像这样的看起来会起作用。它似乎也使部署变得简单。并且，它可以自动化，这很好。但它并不像最优雅或可扩展的解决方案。
另一种方法似乎是生成名称空间的这种功能方法（https://github.com/jashkenas/coffee-script/wiki/Easy-modules-with-CoffeeScript）。这似乎是一个聪明的解决方案。我测试了它并且它可以工作，但我想知道是否有性能或其他缺点。它似乎也可以与上述方法结合使用。
另一个选项似乎是将类和函数分配/导出到window对象。听起来这是一种相当标准的方法，但我很好奇这是否真的是最好的方法。
我尝试使用Spine，因为它似乎可以解决这些问题，但遇到了启动和运行的问题（无法安装spine.app或下摆），我怀疑它使用了一个或多个以上技术无论如何。如果javascriptMVC或骨干解决了这些问题，我会感兴趣 - 我也会考虑它们。
感谢您的想法。
答案 0 :(得分：1)
另一个选项似乎是将类和函数分配/导出到window对象。听起来这是一种相当标准的方法，但我很好奇这是否真的是最好的方法。
我会说是的。看看那个wiki页面的历史，在编译之前提倡.coffee文件连接的人是Stan Angeloff，早在2010年8月，在Sprockets 2（Rails 3.1的一部分）之类的工具可用之前。这绝对不是标准方法。
您不希望多个.coffee文件共享相同的范围。这与语言的设计背道而驰，该语言将每个文件包装在范围包装器中是有原因的。必须将全局变量附加到window以使其全局化，这样才能使您免于犯下JavaScripters遇到的最常见错误之一。
是的，帮助程序重复复制可能会导致一些低效率，并且在编译期间有一个open discussion选项可以禁用帮助程序输出。但影响很小，因为帮助者不太可能只占代码的一小部分。
如果javascriptMVC或骨干解决了这些问题，我会感兴趣
JavaScript MVC和BackBone在范围问题方面没有做任何事情，除非它们导致您将数据存储在全局对象而不是局部变量中。当你说Spine“似乎可以解决这些问题”时，我不确定你的意思;如果你发布另一个更具体的问题，我会很感激。
答案 1 :(得分：0)
如果你更喜欢node.js模块系统，这会在浏览器中提供相同的内容：https://github.com/substack/node-browserify
档案foo.coffee：
module.exports = class Foo
...
档案bar.coffee：
Foo = require './foo'
# do stuff