使用RequireJS的Javascript名称空间，为什么？

我目前正面临关于javascript上名称空间的争论，我需要社区的意见

场景： 负责这个项目的架构师不知何故致力于RequireJS，并且非常想使用它

我必须说，该应用程序是一个后台应用程序，以向导的形式部署，因此您可以在6页上来回浏览一些复杂的业务逻辑，最后填充一些我可以描述为流程请求的内容

好的，没有单页应用程序，在这些问题上没有什么特别之处。普通的backoffice web应用程序，多页，具有非常复杂的UI，其中每个页面都被请求到服务器，所有资源（css、javascript等）都必须在页面加载时加载

主要问题：了解我们所谈论的应用程序类型，首先为什么要使用RequireJS

第二个问题：为什么要试图说服人们在JavaScript中使用名称空间的最佳方法是使用RequireJS？我错过什么了吗

我的意见： 对我来说，这毫无意义。 在这里使用RequireJS很麻烦，因为没有按需加载资源，它们都是在页面加载时加载的（只是因为我们需要在页面加载时加载它们）。 我们至少需要支持IE8、Chrome、Firefox和Opera，而且我们已经在所有这些浏览器的资源加载方面遇到了很多麻烦。通过Require确保所有内容都按预期加载已经有很多技巧

对于名称空间，情况更糟。当然，它是有效的，但再一次，对我来说似乎很麻烦，在这个问题上实际上是非常有限的

我是不是错过了什么？ 我需要第三个（或第100个）意见

• 你觉得这个怎么样
• 你用什么
• 为什么?

提前感谢

AMD装载机（RequireJS就是其中之一）解决了不同的问题：

• 适当的模块化、关注点分离
• 无全球污染
• 没有名字冲突
• 按需加载或部署前优化
• 根据加载程序的不同，可以使用插件处理高级问题，如本地化资源或加载时编译

---

我非常喜欢这种加载程序，发现它们除了非常小的单页应用程序外，对任何东西都有用。

在我个人看来，使用javascript模块系统几乎从来都不是一个坏主意。Requirejs也不是javascript模块唯一可能的加载程序（但可能是最流行的加载程序）。有些替代品是LabJ或HeadJ

这些装载机通常很容易使用（一开始没什么麻烦），但当项目越来越大时，它们会有很大帮助。它们避免了全局空间中的命名冲突，还可以通过最小化/优化模块在部署步骤中为您提供支持。最重要的事实是，它们允许您编写更多模块化的javascript代码

• 你有一些实用功能吗？只需创建一个实用模块
• 您在所有页面上都有一些需要的功能吗？将它们放在一个公共模块中
• 有些页面需要很多特定的javascript代码？为这些页面创建一个额外的模块，这样您就不必在其他页面上加载此代码

无论它是否是“单页应用程序”，RequireJS在开发客户端JavaScript时，如果没有很多开发人员的自律，就有两件事很难做到：

生产与开发环境的对比

到目前为止，将JavaScript应用程序拆分为逻辑上类似于应用程序不同部分的文件是常识。它更容易调试和维护。然而，在生产环境中，运送许多未压缩的文件对性能不利。因此，您将所有文件连接到一个文件中，缩小它（例如，使用Google closure编译器），然后将其作为一个gzip文件发送。使用命令行工具（例如使用）有许多不同的方法来实现这一点，但是如果没有像RequireJS这样的脚本加载程序，您必须自己为两种不同的用例设置页面（将所有开发文件作为脚本标记或单个production.js引用）。RequireJS有一个NodeJS构建工具，可以为您完成所有这些

模块化

现在，将代码保存在单独的文件中是很好的。但是由于JavaScript的本质以及所有的东西都是全局性的，这意味着你仍然会遇到一些奇怪的事情，比如名字冲突。这就是名称空间的用武之地。但更好的选择是将所有内容包装到自己的函数中（引入自己的范围）。这就是为什么大多数JavaScript代码都是自动执行的匿名函数。如果此函数现在返回它想要公开的API，那么您就有了web模块。您可以将模块API与应用程序分开测试，并在其他地方重复使用

---

另外，请阅读RequireJS文档中的部分。

我目前防止全球环境污染和名称冲突的解决方案是使用

$.extend

文件系统树如下所示：

RootFolder
  +-> js
  global.js
  ...
   +-> views
       index.js
       page1.js
       page2.js
       ...
index.html
page1.html
page2.html

所以它通常是一个包含所有应用程序共享代码的global.js文件，每个页面有一个特定的文件

对于名称空间，我喜欢$.extend，因此在每个js文件上我都有如下内容：

var app = app || {};  

/* only one document ready block per view if needed */
$(document).ready(function(){
    /* initialization code */
});

/* extend the app namespace with the Page1 code */
$.extend(app, {
    page1: {
        SayHi: function SayHi(name){
            alert('Hi ' + name);
        }
    }
});

因此，您可以通过调用以下命令访问您的代码：

app.page1.SayHi("Alex");

使用此技术，您可以：

• 完全控制你的代码。没有魔法资源加载和你无法完全控制的奇幻东西
• 没有全球环境污染
• 没有命名冲突
• 名称空间树可以像您希望的那样深，您拥有自己的复杂性
• 您可以有多个js文件，它们实际上对同一命名空间级别做出贡献。这在辅助工具上特别有用
• 根据页面上包含的javascript文件，您可以拥有更大或更小的应用程序名称空间

结论：

Web环境非常简单，w