将 Require.js 与 Angular.js 一起使用是否有意义？[已关闭]

是的，与其中可用于模块化组件一起使用是有意义的。angular.jsrequire.jsrequire.js

有一个种子项目使用 .both angular.js and require.js

重申我认为OP的问题到底是：

如果我主要在Angular 1.x中构建一个应用程序，并且（隐式地）在Grunt / Gulp / Broccoli和Bower / NPM的时代这样做，并且我可能有几个额外的库依赖项，那么Require是否除了使用Angular而不需要获得的价值之外增加了清晰，特定的价值？

或者，换句话说：

“如果我有其他处理基本脚本加载的方法，vanilla Angular 是否需要需要有效地管理基本的 Angular 组件加载？"

我相信对此的基本答案是：“除非你有其他事情发生，和/或你无法使用更新，更现代的工具。

让我们在一开始就明确一点：RequireJS是一个很棒的工具，它解决了一些非常重要的问题，并开始了我们前进的道路，朝着更具可扩展性，更专业的Javascript应用程序迈进。重要的是，这是许多人第一次遇到模块化的概念，以及将事物从全球范围中解脱出来的概念。因此，如果您要构建一个需要扩展的Javascript应用程序，那么Require和AMD模式并不是做到这一点的坏工具。

但是，Angular 有什么特别之处使 Require/AMD 特别适合吗？不。事实上，Angular为您提供了自己的模块化和封装模式，这在很多方面都使AMD的基本模块化功能变得冗余。而且，将Angular模块集成到AMD模式中并非不可能，但它有点......挑剔。您肯定会花时间让这两种模式很好地集成。

从Angular团队本身的角度来看，Brian Ford是Angular Batarang的作者，现在是Angular核心团队的成员：

我不建议将 RequireJS 与 AngularJS 一起使用。虽然这当然是可能的，但我还没有看到任何需要JS在实践中有益的实例。

因此，关于AngularJS这个非常具体的问题：Angular和Require/AMD是正交的，并且在重叠的地方。你可以一起使用它们，但是没有理由与Angular本身的性质/模式特别相关。

但是，对可扩展Javascript应用程序的内部和外部依赖关系进行基本管理呢？不需要在那里做一些对我真正重要的事情吗？

我建议看看Bower和NPM，特别是NPM。我并不是想就这些工具的相对优势展开一场圣战。我只想说：还有其他方法可以剥那只猫的皮，这些方法可能比AMD / Require更好。（它们在2015年末肯定有更受欢迎的势头，特别是NPM，与ES6或CommonJS模块相结合。请参阅相关的 SO 问题。

延迟加载呢？

请注意，延迟加载和延迟下载是不同的。Angular的延迟加载并不意味着你直接从服务器中提取它们。在具有javascript自动化的Yeoman风格的应用程序中，您将整个shebang连接并缩小到一个文件中。它们存在，但直到需要时才执行/实例化。您从中获得的速度和带宽改进远远超过了延迟下载特定20行控制器的任何所谓的改进。事实上，该控制器浪费的网络延迟和传输开销将比控制器本身的大小大一个数量级。

但是，假设您确实需要延迟下载，也许对于应用程序中不经常使用的部分，例如管理界面。这是一个非常合理的案例。Require确实可以为您做到这一点。但还有许多其他可能更灵活的选项可以完成同样的事情。Angular 2.0显然会为我们解决这个问题，内置于路由器中。（详细信息。

但是在我的本地开发盒上进行开发时呢？

如何加载所有数十/数百个脚本文件，而无需将它们全部附加到索引.html手动？

看看Yeoman的generator-angular中的子生成器，或者generator-gulp-angular中体现的自动化模式，或者 React的标准Webpack自动化。这些为您提供了一种干净，可扩展的方式：在组件搭建基架时自动附加文件，或者如果它们存在于某些文件夹中/匹配某些glob模式，则简单地自动获取所有文件。一旦你有了后一个选项，你就再也不需要考虑自己的脚本加载了。

底线？

对于某些事情，Require是一个很好的工具。但是，只要有可能，就要与谷物一起去，并尽可能分开你的关注点。让Angular担心Angular自己的模块化模式，并考虑使用ES6模块或CommonJS作为通用模块化模式。让现代自动化工具无需担心脚本加载和依赖关系管理。并以细粒度的方式处理异步延迟加载，而不是将其与其他两个问题纠缠在一起。

也就是说，如果您正在开发Angular应用程序，但由于某种原因无法在计算机上安装Node以使用Javascript自动化工具，那么Require可能是一个很好的替代解决方案。我见过非常复杂的设置，人们想要动态加载Angular组件，每个组件都声明自己的依赖项或其他东西。虽然我可能会尝试以另一种方式解决这个问题，但我可以看到这个想法的优点，对于这种非常特殊的情况。

但除此之外...当从头开始使用新的Angular应用程序和灵活性来创建现代自动化环境时...你还有很多其他的，更灵活，更现代的选择。

（反复更新以跟上不断发展的JS场景。