在具有可扩展性的Javascript的世界里，当我们说应用程序是模块化的时候，我们的意思常常是它包含着一些高度解耦的各自独立的存储在模块中的功能块。松耦合便于通过移除依赖从而在可能的时候对应用进行维护。当这样的便利性得到了有效实现的时候，就可以相当容易的看到系统的一个部分对其它部分可能产生的影响如何发生改变。
然而不像一些更加普遍的传统的编程语言，JavaScript（ECMA-262）的当前版本并没有使用一种干净，结构化的方式为开发者提供导入此模块的方法。它是直到近几年对于更加结构化的Javascript应用程序的需求变得更加明显，才作为规范需要着重考虑的问题之一。
反过来，现在的开发者只剩下回到带有变异性质的模块或者对象语法模式，这我们已经在本书的前面部分涵盖到了。许多这些用于模块化的脚本使用被描述成为全局对象的命名空间在DOM中串在一起，仍然有可能在我们的架构中产生命名冲突。缺少一些手工的尝试或者第三方插件的帮助，这也不是一种控制依赖管理的干净的方法。
虽然对于这些问题的本地解决方案将会到达ES Harmony(很有可能成为Javascript的下一个版本)，好消息是编写模块化的Javascript从来没有变得更加简单，而我们今天开始就可以开始这样做了。
在本节中，我们将看一看编写模块化Javascript的三种形式：AMD， CommonJS和建议的Javascript的下一个版本，Harmony
在没有谈及房间里的大象——脚本加载器之前，要讨论AMD和CommonJS的模块是很困难的。在写这本书的时候，脚本加载意味着一个目标，那个目标就是可以在今天的应用程序中使用的模块化的Javascript——为此，使用与此兼容的脚本加载器，很不幸的说是必需的。为了能尽可能的获取这一节的信息，我建议先对流行的脚本加载工具如何工作有一个基本的理解，以便在本文中对于模块化形式的解释有意思起来。
在AMD和CommonJS形式中有大量用于处理模块加载的加载器，而我个人的选择是RequireJS和curl.js。对于这些工具的完整教程超出了本书的范畴，但是我建议去读John Hann的关于curl.js的文章，和James Burke的RequireJS API文档，以获取更多信息。
对于生产环境而言，使用优化工具（像RequireJS优化器）的来连结脚本，被提倡在这样的模块上工作时用于部署。有趣的是，有Almond AMD垫底，RequireJS并不需要卷入被部署的站点中，而人们可能会考虑的脚本加载器能够简单的在开发工作的外围进行切换。
那就是说，James Burke将可能声称可以在页面加载直到有用武之地后才动态加载脚本，并且RequireJS也能支持这一特性。将这些要点铭记于心了，那就让我们开始吧。