浏览器的细节§ 1

XMLHttpRequest(XHR)加载程序仅限于与页面相同的域,从而使调试更加困难。某些浏览器在使用eval时允许跨域XHR调用和更好的调试约定,但跨浏览器的支持不一致。

应避免使用基于评估程序的加载程序,因为评估方法不是JavaScript的最佳做法,在某些环境中不允许这样做。评估有一个时间和地点,但是模块加载器比使用它更好。

也不需要服务器进程即时转换脚本。让每个人都使用相同的服务器进程,甚至制定他们都可以发出的通用格式的规范,这会增加开销,增加编写工作。前端开发人员具有悠久的实践,即能够编写纯文本文件并将其加载到浏览器中,而无需使用大量服务器硬件。

通过脚本标签加载的脚本可以在任何地方使用,并且可以跨域使用。这是一种使用浏览器自然加载脚本的简单加载方式。

在页面加载之前和之后加载代码§ 2

页面加载前后应使用同一系统。将代码的加载延迟到以后的页面操作之前是一个关键的性能优势。

脚本应该能够指定依赖关系§ 3

一个项目很简单,不需要几个脚本。很难手动跟踪所有依赖关系和正确的加载顺序。脚本应该能够指定其直接依赖性。开发人员不必担心那些依赖项需要加载什么并制定正确的加载顺序。

加载程序应该能够加载嵌套的依赖项§ 4

如果每个模块都指定了自己的直接依赖关系,则加载程序应该能够在整个系统中计算出正确的依赖关系,甚至是嵌套依赖关系,以获取依赖关系。

需要根据依赖关系评估模块§ 5

使用具有嵌套依赖项解析并且在页面加载之后才能工作的浏览器本机脚本加载,意味着至少需要在部分时间通过使用appendChild作为脚本元素来加载脚本。

IE和WebKit将以DOM顺序执行通过appendChild添加的脚本,它们以网络接收顺序执行脚本。即使它们按照添加到DOM中的顺序执行脚本,也将在模块脚本加载后发现模块的依赖关系,因此依赖关系的脚本将始终添加在需要它们的脚本之后。

这导致为脚本构造一种模块格式,该模块格式将脚本的大部分内容放入一个函数中,并且其依赖关系在该函数包装器之外指定。这允许浏览器对脚本进行无序评估,但有机会正确地计算出依赖项,然后按正确的顺序调用函数包装器以使脚本成为现实。

模块格式应紧凑§ 6

样板代码很痛苦。但是,需要函数包装作为样板的一部分。最好使样板尽可能简洁,以允许开发人员轻松进行手工编码。避免对每个属性使用名称/值对的过于明确的模块格式,因为开发人员必须手动编写这些格式。

拥有精简的核心加载程序,但考虑到未来§ 7

加载程序的核心(具有嵌套依赖项解析的模块格式支持)应该是紧凑的,但允许插件扩展依赖项的概念及其加载的含义。

在Dojo中,通常需要i18​​n字符串捆绑和HTML文本字符串来构建小部件。允许加载程序能够加载这些内容,但是可以作为插件加载,因此核心保持轻量级。

允许模块保持干净的全局名称空间§ 8

随着项目的扩大,在页面中加载模块的两个版本更为普遍。通过允许在全局名称空间中未定义模块的模块系统,应该可以做到这一点。

如果模块要使用全局名称空间,通常很容易在模块规范中允许使用。最困难的部分是构造一种可以很好地避免使用全局名称空间的格式。

加载任何脚本§ 9

并非所有脚本都将使用模块格式。允许加载现有脚本并将其视为依赖项。

允许性能升级§ 10

这主要意味着拥有可以组合和优化模块的构建系统。这也意味着加载程序应允许加载一个脚本,该脚本中定义了多个模块,并且只能获取该脚本文件中尚未包含的依赖项。