Requirejs vs browserify vs webpack 的 js 加载顺序：我只是将情况从一侧移动到另一侧吗？
Requirejs vs browserify vs webpack for js loading order: am I just moving the situation from one side to another?
好的，现在是 2016 年。Webpack looks like a winner against requirejs and browserify。我一直在阅读这 3 种技术，以解决一个非常具体的问题。 我想在我的 HTML 文件（AngularJS 应用程序的一部分）中避免这种情况
<script src="some-file.js"></script>
<script src="some-file2.js"></script>
<script src="some-file3.js"></script>
<!-- Dozens of similar lines here... -->
当然，这些行在我的 HTML 文件中的顺序很重要。 Bootstrap 会要求 jQuery，等等
我发现的第一件事：requirejs。您只需指定如下内容：
<script src="my-bundled-file.js"></script>
然后，你用JS解决了依赖问题。更进一步，我在这里找到了两种方法：
- CommonJS（浏览器化）
- AMD (require.js)
Webpack 适用于这两种方法，听起来不错。
最后，这 3 个工具可以用于同一件事：将多个文件捆绑在一个文件中。但我担心的是这些文件的捆绑顺序。
我不想关心这个，看起来像使用那些解决方案（甚至 gulp + gulp-concat，就像建议的 here), I'm just moving the problem: now, I specify the modules which my application uses with JS code, but I still need to put the modules in the correct order, even with WebPack (an example here: require 来电顺序必须正确）
所以，我的问题：
- 我是不是误解了这些工具？只想解决加载顺序问题，貌似没做
- 这些工具是否解决了不同的问题（ES5 中缺少原生模块，这会导致污染全局范围）？
am I misunderstanding these tools? I just want to solve the loading order problem, and looks like I'm not doing it
我想是的，是的。使用 CommonJS 和捆绑它的工具，加载顺序在很大程度上变得无关紧要，这是您不需要管理的事情。您只需 require() 您需要的地方即可。在某些情况下它仍然相关，但主要与全局副作用和循环依赖性等问题有关。使用 CommonJS 并将其捆绑与连接一系列脚本完全不同。
do these tools solve a different problem (lack of native modules in ES5, which drives to contaminate the global scope)?
CommonJS 模块系统旨在解决 JavaScript 中缺少本机模块的问题，并且在 Node.js 中使用了它的一个版本。 Browserify 上的标题是 "bundle node modules for the browser"，但在实践中它也用于在 Node 中创建到 运行 的包，以及用于在浏览器中仅用于 运行ning 的捆绑模块。
在 Node 中不需要捆绑模块，因为 Node 包装了您执行的代码并为其模块语义提供了实现。要在浏览器中使用该系统的 运行 模块，您需要将其捆绑，因为浏览器不会包装代码以向其提供构成模块接口的内容，例如 require()、module, exports.这是捆绑器为您所做的一部分：包装代码以提供该接口。
它为您做的另一件事是递归地发现依赖关系，解决您关于排序的问题。所以就像我说的，你 require() 你需要的东西在你需要的地方，然后将捆绑器指向入口脚本。捆绑器将分析脚本以查找任何 require() 并将它们引用的模块包含在捆绑包中。对于那些模块，它将无限重复。
我认为您会发现 CommonJS 比 AMD 更有吸引力，但我想说 Webpack 远未明显胜过 Browserify。两者都很受欢迎。 Browserify 被广泛使用，包括构建部分项目，如 Babel 和 React。
我的建议是从 Node-style CommonJS 模块和 Browserify 开始（注意：我是 Browserify 的维护者）。
在你更好地理解这一点之前，我建议不要使用涉及 Angular 的任何内容作为关于如何根据 CommonJS 模块化完成工作的参考。我认为他们在将 Angular npm 包转换为正确的 CommonJS 形状时遇到了很多麻烦。
好的，现在是 2016 年。Webpack looks like a winner against requirejs and browserify。我一直在阅读这 3 种技术，以解决一个非常具体的问题。 我想在我的 HTML 文件（AngularJS 应用程序的一部分）中避免这种情况
<script src="some-file.js"></script>
<script src="some-file2.js"></script>
<script src="some-file3.js"></script>
<!-- Dozens of similar lines here... -->
当然，这些行在我的 HTML 文件中的顺序很重要。 Bootstrap 会要求 jQuery，等等
我发现的第一件事：requirejs。您只需指定如下内容：
<script src="my-bundled-file.js"></script>
然后，你用JS解决了依赖问题。更进一步，我在这里找到了两种方法：
- CommonJS（浏览器化）
- AMD (require.js)
Webpack 适用于这两种方法，听起来不错。
最后，这 3 个工具可以用于同一件事：将多个文件捆绑在一个文件中。但我担心的是这些文件的捆绑顺序。
我不想关心这个，看起来像使用那些解决方案（甚至 gulp + gulp-concat，就像建议的 here), I'm just moving the problem: now, I specify the modules which my application uses with JS code, but I still need to put the modules in the correct order, even with WebPack (an example here: require 来电顺序必须正确）
所以，我的问题：
- 我是不是误解了这些工具？只想解决加载顺序问题，貌似没做
- 这些工具是否解决了不同的问题（ES5 中缺少原生模块，这会导致污染全局范围）？
am I misunderstanding these tools? I just want to solve the loading order problem, and looks like I'm not doing it
我想是的，是的。使用 CommonJS 和捆绑它的工具，加载顺序在很大程度上变得无关紧要，这是您不需要管理的事情。您只需 require() 您需要的地方即可。在某些情况下它仍然相关，但主要与全局副作用和循环依赖性等问题有关。使用 CommonJS 并将其捆绑与连接一系列脚本完全不同。
do these tools solve a different problem (lack of native modules in ES5, which drives to contaminate the global scope)?
CommonJS 模块系统旨在解决 JavaScript 中缺少本机模块的问题，并且在 Node.js 中使用了它的一个版本。 Browserify 上的标题是 "bundle node modules for the browser"，但在实践中它也用于在 Node 中创建到 运行 的包，以及用于在浏览器中仅用于 运行ning 的捆绑模块。
在 Node 中不需要捆绑模块，因为 Node 包装了您执行的代码并为其模块语义提供了实现。要在浏览器中使用该系统的 运行 模块，您需要将其捆绑，因为浏览器不会包装代码以向其提供构成模块接口的内容，例如 require()、module, exports.这是捆绑器为您所做的一部分：包装代码以提供该接口。
它为您做的另一件事是递归地发现依赖关系，解决您关于排序的问题。所以就像我说的，你 require() 你需要的东西在你需要的地方，然后将捆绑器指向入口脚本。捆绑器将分析脚本以查找任何 require() 并将它们引用的模块包含在捆绑包中。对于那些模块，它将无限重复。
我认为您会发现 CommonJS 比 AMD 更有吸引力，但我想说 Webpack 远未明显胜过 Browserify。两者都很受欢迎。 Browserify 被广泛使用，包括构建部分项目，如 Babel 和 React。
我的建议是从 Node-style CommonJS 模块和 Browserify 开始（注意：我是 Browserify 的维护者）。
在你更好地理解这一点之前，我建议不要使用涉及 Angular 的任何内容作为关于如何根据 CommonJS 模块化完成工作的参考。我认为他们在将 Angular npm 包转换为正确的 CommonJS 形状时遇到了很多麻烦。