我正在研究一种使用允许需要 Javascript 模块的 CommonJS 结构由 BackboneJS 应用程序编写的方法。然后，此应用程序可以使用节点在客户端或服务器端工作。
我已经研究了requirejs和其他类似的选项，但是您必须以特定的方式编写应用程序，在我看来这看起来真的很糟糕。
我还查看了browserify和webmake，它们获取您的代码和所需的任何模块，并将它们组合成一个带有缺失 (require) 方法的单个 js 文件。都是一个聪明的主意，但是让客户端的代码有点混乱。
有没有这样的东西可以通过以commonJS格式编写的代码，编译与浏览器兼容的所有必需模块并吐出一个可以在浏览器中使用而不必担心的Javascript文件（或多个）关于缺少 require 方法？更好的是为骨干应用量身定制的解决方案。
在浏览器中使用 CommonJS 结构化模块有多种选择：
cjsTranslate。在您的 r.js 优化器配置中将此设置为cjsTranslate: true将使用样板包装任何包含的看起来是 CommonJS 格式的模块define。在此处查看详细信息。define样板文件中。我相信这是他们在SoundCloud采用的方法- 请参阅此博客文章。2014 年 8 月 29 日编辑：可以说，这里的当前最佳实践是Browserify ，它带有生成的源映射，以便于客户端调试。
我不清楚为什么像 webmake 这样的东西不能解决你的问题。
它不需要您以任何与服务器端模块不同的方式编写客户端模块。
你提出了 webmake/browerify 对 js 的影响。好吧，你猜怎么着。RequireJS/Curl 做同样的事情。是的，我知道，不一定，但在大约 2012 年的任何实际生产情况下，您将拥有某种工具来组合您的 js 并在通过网络发送之前将其缩小。
@rharper 当前接受的答案中的前三点基本上列出了 AMD 加载程序空间中的替代方案。AMD 作为一个概念肯定与 Common JS 非常不同，并且解决了一个非常有效的问题，而该问题却没有引起 CJS 规范编写者的注意。但这是对未来的一个有效关注，因为目前的脚本大小与图像等相比相形见绌。当脚本大小成为一个值得注意的性能问题时，我们可能会拥有 ECMA Harmony 模块，它应该具有本机浏览器支持. （即使在今天，也没有什么能阻止您手动将模块拆分为逻辑组并要求在需要时加载每个组合组。只是不需要经常这样做）。
webmake 是@rharper 列出的第四个替代方案的（某种）实现。我提倡 webmake 而不是 browserify，因为 webmake 在其授权中声明它只应该做一件事 - 在您编写了一堆模块并通过require("foo")andexports.bar = ...机制声明了它们的依赖关系之后，您运行一个指定初始 javascript 文件的命令，并且它吐出一个 js 文件，其中包含所有可传递发现的依赖项。在我使用它的有限经验中，它做得很好。以最小的开销 - 仅添加 75 奇数行非缩小代码作为序言。
如果在开发过程中有额外的构建步骤会导致摩擦，您也可以动态地重新生成组合的 js 并通过 node.js 服务器（几行代码）提供它。webmake 还支持源映射，因此在 webkit 浏览器中调试也可以。
请记住，我建议使用 webmake，因为经过大量搜索，这是我遇到的最简单的解决方案。但这并不意味着它对你有用。在这个领域有这么多替代品的原因是因为每个人都有自己的一套花里胡哨，其中一些可能对您的用例至关重要。但一般原则适用于大多数优秀的 javascript 加载器：
无论您使用 AMD 还是 CJS，都不需要编写 AMD 样板。@rharper 列出了一些支持自动执行此操作的 AMD 替代方案。
您应该有两条不同的生产和开发路径。从今天开始，生产 javascript 应该被缩小/组合。开发 javascript 不应该，也不需要在保存（在编辑器中）/重新加载（页面）/调试（在浏览器中）循环中添加额外的步骤。