AMD（异步模块定义，Asynchronous Module Definition）格式总体的目标是为现在的开发者提供一个可用的模块化 JavaScript 的解决方案。
根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在一个文件定义的变量（还包括函数和类），都是私有的，对其他文件是不可见的。
前端发展到今天，已经有不少模块化的方案，比如AMD、CMD、UMD、CommonJS等，当然了，还有es6带来的模块系统，这些模块化规范的核心价值都是让 JavaScript 的模块化开发变得简单和自然，今天就来看看这些规范都是啥。 为什么要模块化 在模块化这东西没出来之前，前端脚本引用大概是这样的： <script src="module1.js"></script> <script src="module2.js"></script> <script src="libraryA.js"><
JavaScript 语言最初是为简单的表单操作而发明的，没有诸如模块或命名空间之类的内置功能。多年以来发明了大量的术语、模式、库、语法和工具来模块化 JavaScript。本文讨论了 JavaScript 中的所有主流模块系统、格式、库和工具，包括：
通用模块定义，umd兼容commonjs和amd规范，这意味着umd规范的模块可以直接引用到commonjs规范的项目和amd规范的项目中。
原文地址：What are CJS, AMD, UMD, and ESM in Javascript?[1] 原文作者：Igor Irianto[2] 译者：Gopal 因为面试也经常问这个问题，所以
1.Rollup 是什么2.CommonJS、AMD、CMD、UMD、ES6 分别的介绍3.ES6 模块与 CommonJS 模块的区别4.模块演进的产物 —— Tree Shaking5.Tree Shaking 应该注意什么
在JavaScript发展初期就是为了实现简单的页面交互逻辑，寥寥数语即可；如今CPU、浏览器性能得到了极大的提升，很多页面逻辑迁移到了客户端（表单验证等），随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀，此时在JS方面就会考虑使用模块化规范去管理。 本文内容主要有理解模块化，为什么要模块化，模块化的优缺点以及模块化规范,并且介绍下开发中最流行的CommonJS, AMD, ES6、CMD规范。本文试图站在小白的角度，用通俗易懂的笔调介绍这些枯燥无味的概念，希望诸君阅读后，对模块化编程有个全新的认识和理解！
上例子通过jquery方法将页面的背景颜色改成红色，所以必须先引入jQuery库，就把这个库当作参数传入。这样做除了保证模块的独立性，还使得模块之间的依赖关系变得明显。
项目地址: diana 文档地址: http://muyunyun.cn/diana/ 造轮子的意义 为啥已经有如此多的前端工具类库还要自己造轮子呢？个人认为有以下几个观点吧： 定制性强，能根据自己的需求为主导延伸开发。万一一不小心还能帮到别人（比如 React 库）； 纸上得来终觉浅，很多流行的库，只是照着它们的 API 进行使用，其实这些库里蕴含着大量的知识、技巧，最好的办法就是仿照它们来写些小 demo，从而体会这些库的精髓； 造轮子的过程中能让自己体会到与平常业务开发不一样的乐趣；比如和日常业务
在ES6之前，javascript并没有提供内置的模块特性，通常是开发者利用js的特性，如对象、闭包、立即执行函数等，开发出模块化技术。
后来有人尝试用对象的方式来书写逻辑模块，但是这种写法有自己的弊端，比如这样的写法暴露了所有的模块成员，模块中的属性有被外部代码更改的风险。
由于CommonJS和AMD都十分流行，但似乎缺少一个统一的规范。于是，UMD(通用模块规范)出现了，它可以同时支持这两种风格。
如果你是 JavaScript 的新手，一些像 “module bundlers vs module loaders”、“Webpack vs Browserify” 和 “AMD vs.CommonJS” 这样的术语，很快让你不堪重负。
Commonjs是以在浏览器环境外构建JavaScript生态系统为目标而产生的项目，比如在服务器或桌面环境中。
前端的发展日新月异，前端工程的复杂度也不可同日而语。原始的开发方式，随着项目复杂度提高，代码量越来越多，所需加载的文件也越来越多，这个时候就需要考虑如下几个问题:
作为前端开发，模块化我们已经耳熟能详，我们平时接触到的 ES6 的 import，nodejs中的require他们有啥区别？
模块化是一个语言发展的必经之路，其能够帮助开发者拆分和组织代码，随着前端技术的发展，前端编写的代码量也越来越大，就需要对代码有很好的管理，而模块化能够帮助开发者解决命名冲突、管理依赖、提高代码的可读性、代码解耦以及提高代码的复用性。
早期的javascript版本没有块级作用域、没有类、没有包、也没有模块，这样会带来一些问题，如复用、依赖、冲突、代码组织混乱等，随着前端的膨胀，模块化显得非常迫切。
服务端 ：NodeJS 服务：CommonJS规范，新版本的Node也可以启用ES6 Module功能
如果没有全局安装@vue/cli-init，还需要先安装@vue/cli-init
其实模块化的诞生不难理解，我们知道因为随着网站逐渐的发展，嵌入网页的Javascript代码越来越庞大，而网页越来越像桌面程序，需要一个团队去分工协作，进行管理和测试等等，为了更好的管理网页的业务逻辑，产生了模块化编程的理念。
AngularJS模块化使用的并不是标准的AMD规范，AngularJS的风格风格大致是这样的：
1、创建一个空对象，并且 this 变量引用该对象，同时还继承了该函数的原型。 2、属性和方法被加入到 this 引用的对象中。 3、新创建的对象由 this 所引用，并且最后隐式的返回 this 。
或许是HTTP2普及的时候。但更大的可能是将来也“不能用”（还是只能在构建工具中用，仅存在于“编译期”）
js本身的问题： 不具有模块化的语法规则，在语言层面没有命名空间。 JavaScript 编程过程中很多时候，我们都在修改变量，在一个复杂的项目开发过程中，如何管理函数和变量作用域，显得尤为重要。
前端模块化是指将一个大型的前端应用程序分解为小的、独立的模块，每个模块都有自己的功能和接口，可以被其他模块使用。
AngularJS 目前的版本没有遵循 Javascript 约定的 AMD 模块化规范， 因此使用 RequireJS 加载 AngularJS 时需要一些额外的配置。
现在回过头来想想，也许选择以《JavaScript权威指南》一书来作为入门有些不好，因为这本书毕竟是很早之前的，书中所讲的思想、标准也基本都只是 ES5 及那时代的相关技术。
三大 JavaScript 主流模块规范：CommonJS、AMD 和 ES6 Module。CommonJS 和 AMD 都未统一浏览器和客户端的模块化规范。目前 Node.js 使用 CommonJS 作为官方的模块解决方案，虽然内置的模块方案促进了 Node.js 的流行，但是也为引入新的 ES Modules（ESM）标准造成了一定的阻碍，不过 Node.js 9.0+ 已经支持 ESM 语法。
rollup.js是一个模块打包工具，可以使项目从一个入口文件开始，将所有使用到的模块文件都打包到一个最终的发布文件中，Rollup极其适合构建一个工具库，Vue.js源码就是通过Rollup打包构建的。
CSS 早在 2.1 的版本就提出了 @import 来实现模块化，但是 JavaScript 直到 ES6 才出现官方的模块化方案 ES Module。尽管早期 JavaScript 语言规范上不支持模块化，但这并没有阻止 JavaScript 的发展。官方没有模块化标准，那么我们就自己动手创建标准。社区里的前辈们创建并实现了规范，这些规范便是前端模块化发展之路上智慧的结晶。
随着前端的发展，页面特效、交互都在前端层面实现，前端的代码逻辑复杂度增加。 写代码不可能一把唆，都写入一个文件当中，这样可读性不强也不利于后期的维护。 需要利用模块的思想将代码进行划分，使其职责单一且可替换。
随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀
构建的核心是资源管理。简单说，构建就是把前端工程师开发的源代码进行编译、压缩、打包等一系列操作，最终产出可以直接上线或者可供后端工程师的资源。 构建可以划分为纯前端构建和前后端协作构建。 这两个不是专业术语，如果你有更合适的称谓，欢迎指正。 所谓纯前端构建，就是说不涉及后端模板的构建，经过构建之后的前端代码可以直接上线。这种情形下大多是数据驱动UI的web应用，模板只负责提供空白的容器和基础的静态资源，UI的文档结构交由前端JavaScript实现。这个过程可以使用一些框架，比如近期较流行的React
AMD（常用在浏览器端，异步的，如requirejs）（Asynchronous Module Definition）
模块，（Module），是能够单独命名并独立地完成一定功能的程序语句的集合（即程序代码和数据结构的集合体）。
从jq官网down下最新的未压缩版代码并打开后，首先看下整体，这就是一个大型的自执行的匿名函数：
在很久以前，js只是简单的作为浏览器的交互操作而存在，一般都是非常短小的脚本，所以都是独立存在的。
=> 揭示模式 revealing => 上层无需了解底层实现，仅关注抽象 => 框架
JavaScript 中的模块，本质上都是为了解决 Js 的作用域问题而定义的模块形式
但为什么要了解 Javascript 模块化发展的历史呢？因为凡事都有两面性，了解 Javascript 模块化规范，有利于我们思考出更好的模块化方案，纵观历史，从 1999 年开始，模块化方案最多维持两年，就出现了新的替代方案，比原有的模块化更清晰、强壮，我们不能被现代模块化方式限制住思维，因为现在的 ES2015 模块化方案距离发布也仅仅过了两年。
模块系统是什么？简单来说，其实就是我们在一个文件里写代码，声明一些可以导出的字段，然后另一个文件可以将其导入并使用。
随着网站功能逐渐丰富，网页中的js也变得越来越复杂和臃肿，原有通过script标签来导入一个个的js文件这种方式已经不能满足现在互联网开发模式，我们需要团队协作、模块复用、单元测试等等一系列复杂的需求
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
