模块化开发是 JS 项目开发中的必备技能，它如同面向对象、设计模式一样，可以兼顾提升软件项目的可维护性和开发效率。
现在回过头来想想，也许选择以《JavaScript权威指南》一书来作为入门有些不好，因为这本书毕竟是很早之前的，书中所讲的思想、标准也基本都只是 ES5 及那时代的相关技术。
2019 年的 4 月份，Node.js 官方团队在发布 Node.js 12 时，也给我们带来了最新的 ECMAScript Modules 支持。
前端发展到今天，已经有不少模块化的方案，比如AMD、CMD、UMD、CommonJS等，当然了，还有es6带来的模块系统，这些模块化规范的核心价值都是让 JavaScript 的模块化开发变得简单和自然，今天就来看看这些规范都是啥。 为什么要模块化 在模块化这东西没出来之前，前端脚本引用大概是这样的： <script src="module1.js"></script> <script src="module2.js"></script> <script src="libraryA.js"><
AMD（Asynchronous Module Definition）异步模块定义，客户端规范。采用异步方式加载模块，模块加载不影响它后面语句的代执行。
这个仓库[1]记录了一些关于javascript UMD模块规范的demo，对我学习UMD规范有了很大帮助，希望也能帮助到你。
js模块化规范有：CommonJS、AMD、CMD、ES6的模块系统。本文将依次介绍下每个规范。
随着前端js代码复杂度的提高，JavaScript模块化这个概念便被提出来，前端社区也不断地实现前端模块化，直到es6对其进行了规范，下面就介绍JavaScript模块化。
CommonJS的核心思想就是通过 require 方法来同步加载所要依赖的其他模块，然后通过 exports 或者 module.exports 来导出需要暴露的接口。
在布达佩斯2022 JSConf会议上，tc39（ES标准委员会）成员Gil Tayar介绍了一份当前仍处于stage 1阶段的提案 —— Type Annotations，意在让原生JS支持类型注解。
在JavaScript发展初期就是为了实现简单的页面交互逻辑，寥寥数语即可；如今CPU、浏览器性能得到了极大的提升，很多页面逻辑迁移到了客户端（表单验证等），随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀，此时在JS方面就会考虑使用模块化规范去管理。 本文内容主要有理解模块化，为什么要模块化，模块化的优缺点以及模块化规范,并且介绍下开发中最流行的CommonJS, AMD, ES6、CMD规范。本文试图站在小白的角度，用通俗易懂的笔调介绍这些枯燥无味的概念，希望诸君阅读后，对模块化编程有个全新的认识和理解！
初学Web前端要注意什么？如何学好JS模块化编程？JavaScript是前端三要素之一，也是很多初学Web前端的人遭遇的第一条拦路虎。很多同学表示JavaScript涵盖的知识点太多太复杂、应用也是五花八门完全摸不着头脑。但只要我们一点一点由基础到进阶的学习，就一定能学好JavaScript，接下来小编就给大家分享有关JavaScript模块化编程的知识。
如今的前端工作中，模块化开发成为主流，无论是前端还是后端，由于模块化开发为我们带来巨大的收益，因此开发者都在使用它。模块化开发部分的面试题主要考察应试者对几种模块化开发规范的了解，应试者要明白它们之间的异同点，以及所适用的场合。
在布达佩斯2022 JSConf[1]会议上，tc39[2]（ES标准委员会）成员「Gil Tayar」介绍了一份当前仍处于stage 1阶段的提案 —— Type Annotations，意在让原生JS支持类型注解。
上一篇《前端科普系列（2）：Node.js 换个角度看世界》，我们聊了 Node.js 相关的东西，Node.js 能在诞生后火到如此一塌糊涂，离不开它成熟的模块化实现，Node.js 的模块化是在 CommonJS 规范的基础上实现的。那 CommonJS 又是什么呢？
答：因为有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。 但是，这样做有一个前提，那就是大家必须以同样的方式编写模块，否则你有你的写法，我有我的写法，岂不是乱了套！
上例子通过jquery方法将页面的背景颜色改成红色，所以必须先引入jQuery库，就把这个库当作参数传入。这样做除了保证模块的独立性，还使得模块之间的依赖关系变得明显。
根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在一个文件定义的变量（还包括函数和类），都是私有的，对其他文件是不可见的。
CSS 早在 2.1 的版本就提出了 @import 来实现模块化，但是 JavaScript 直到 ES6 才出现官方的模块化方案 ES Module。尽管早期 JavaScript 语言规范上不支持模块化，但这并没有阻止 JavaScript 的发展。官方没有模块化标准，那么我们就自己动手创建标准。社区里的前辈们创建并实现了规范，这些规范便是前端模块化发展之路上智慧的结晶。
通用模块定义，umd兼容commonjs和amd规范，这意味着umd规范的模块可以直接引用到commonjs规范的项目和amd规范的项目中。
JS本身是一个多才多艺的语言，一个可以用自己编译自己的自由度极高的语言。正因为这份自由，出现了天花乱坠的规范与框架们，其中最基础的一块便是Module。
requireJS（http://www.requirejs.cn/）是一个JavaScript模块加载器。它非常适合在浏览器中使用，使用RequireJS加载模块化脚本将提高代码的加载速度和质量。
其实模块化的诞生不难理解，我们知道因为随着网站逐渐的发展，嵌入网页的Javascript代码越来越庞大，而网页越来越像桌面程序，需要一个团队去分工协作，进行管理和测试等等，为了更好的管理网页的业务逻辑，产生了模块化编程的理念。
如果要从JS中找一个API作为整个前端的缩影，ESM规范中的import再合适不过了。
适用于前端开发团队规范为参考规范，不全是硬性要求，统一团队编码规范和风格。让所有代码都是有规可循的，并且能够获得沉淀，减少重复劳动。
1、为什么要使用模块化 最主要的目的 解决命名冲突 便于依赖管理 其他价值 提高代码可读性 代码解耦，提高复用性 2、CMD、AMD、CommonJS 规范分别指什么？有哪些应用 1、CMD规范 CMD 即Common Module Definition通用模块定义，CMD规范是国内发展出来的，就像AMD有个requireJS，CMD有个浏览器的实现SeaJS，SeaJS要解决的问题和requireJS一样，只不过在模块定义方式和模块加载（可以说运行、解析）时机上有所不同。 // 定义模块 myMo
正如当年为了统一 JavaScript 语言标准，人们制定了 ECMAScript 规范一样，如今为了统一 JavaScript 在浏览器之外的实现，CommonJS 诞生了。CommonJS 试图定义一套普通应用程序使用的 API，从而填补 JavaScript 标准库过于简单的不足。CommonJS 的终极目标是制定一个像 C++ 标准库一样的规范，使得基于 CommonJS API 的应用程序可以在不同的环境下运行，就像用 C++ 编写的应用程序可以使用不同的编译器和运行时函数库一样。为了保持中立，CommonJS 不参与标准库实现，其实现交给像 Node.js 之类的项目来完成。
我们来说全局配置，我们知道导入require.js之后会设置data-main属性来执行入口文件，然后再入口文件中进行require的配置。
本章在上章内容的基础上简单扩展一下，先说下模块的规范，有哪些标准，然后谈下webpack的loader怎么用以及使用webpack中的babel-loader简单打包一下。 git仓库：webpack-demo 1、模块化规范 上章我们知道webpack是一个模块打包工具，何为模块？一个js文件、css等等都可以称之为模块，ok，假设现在我有a.js、b.js、c.js等等，而且它们之间还要相互引用，咋整？这时候就需要有一套标准来定义该怎么引用啊，它们之间是个啥依赖关系啊之类的，那么大概就有这么几种
相对于其他静态语言，JS最大缺陷就是天生不具有模块化，没有语言层面的命名空间的概念。问题如下：
技术的诞生是为了解决某个问题，模块化也是。 随着前端的发展，web技术日趋成熟，js功能越来越多，代码量也越来越大。之前一个项目通常各个页面公用一个js，但是js逐渐拆分，项目中引入的js越来越多. 在js模块化诞生之前，开发者面临很多问题:
上面说提到的结构，就是模块；按照这种结构划分开发程序的过程，就是模块化开发的过程；
AMD（常用在浏览器端，异步的，如requirejs）（Asynchronous Module Definition）
大家都知道，在nodejs 中，引入模块用 require ; 而在react 与vue 等前端框架中，用的是import ;
在浏览器中网页加载中 javascript 的 加载 和 执行会默认阻塞 DOM 的加载和页面的渲染。 因此，在编写代码的时候我们往往将 script 标签放到 body 的最后面。 当然，也可以通过异步创建 script 标签的方式来实现 js的异步加载。
javascript语言实现,ES6规范（使用babel编译器将es6转换为es5，webpack只支持部分es6）：
对于web项目来说，打交道的不仅仅有后台，前台页面也是少不了的，而前台的页面js也常常是我们后台程序员必须要使用的语言， 今天说下项目中的js的组织方式。
项目地址: diana 文档地址: http://muyunyun.cn/diana/ 造轮子的意义 为啥已经有如此多的前端工具类库还要自己造轮子呢？个人认为有以下几个观点吧： 定制性强，能根据自己的需求为主导延伸开发。万一一不小心还能帮到别人（比如 React 库）； 纸上得来终觉浅，很多流行的库，只是照着它们的 API 进行使用，其实这些库里蕴含着大量的知识、技巧，最好的办法就是仿照它们来写些小 demo，从而体会这些库的精髓； 造轮子的过程中能让自己体会到与平常业务开发不一样的乐趣；比如和日常业务
JavaScript中所有对象的属性都是公共的，并没有什么明确的方法来表明属性能否从对象的外部被访问，而有时候我们并不希望对象的属性被外界访问。一种方式方式通过命名约定的形式，比如在变量的前面加下划线（_）。还有一些其他的方式是属性完全私有化。
exports和module.exports的适用误区
CommonJs、AMD、CMD、ES6都是用于模块化定义中使用的规范，其为了规范化模块的引入与处理模块之间的依赖关系以及解决命名冲突问题，并使用模块化方案来使复杂系统分解为代码结构更合理，可维护性更高的可管理的模块。
使用webpack对脚本进行合并是非常方便的，因为webpack实现了对各种不同模块规范的兼容处理，对前端开发者来说，理解这种实现方式比学习如何配置webpack更为重要，本节的内容实用性较低。
后来有人尝试用对象的方式来书写逻辑模块，但是这种写法有自己的弊端，比如这样的写法暴露了所有的模块成员，模块中的属性有被外部代码更改的风险。
三大 JavaScript 主流模块规范：CommonJS、AMD 和 ES6 Module。CommonJS 和 AMD 都未统一浏览器和客户端的模块化规范。目前 Node.js 使用 CommonJS 作为官方的模块解决方案，虽然内置的模块方案促进了 Node.js 的流行，但是也为引入新的 ES Modules（ESM）标准造成了一定的阻碍，不过 Node.js 9.0+ 已经支持 ESM 语法。
CommonJS API定义很多普通应用程序（主要指非浏览器的应用）使用的API，从而填补了这个空白。 它的终极目标是提供一个类似Python，Ruby和Java标准库。 这样的话，开发者可以使用CommonJS API编写应用程序，然后这些应用可以运行在不同的JavaScript解释器和不同的主机环境中。
本文首发于政采云前端团队博客：动态表单之表单组件的插件式加载方案 https://www.zoo.team/article/dynamic-form-loading-method
AngularJS模块化使用的并不是标准的AMD规范，AngularJS的风格风格大致是这样的：
随着web2.0时代的到来，Ajax技术得到广泛应用，jQuery等前端库层出不穷，前端代码日益膨胀
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
腾讯会议
实时音视频
