js模块化开发

前言：模块化开发需求 在JS早期，使用script标签引入JS，会造成以下问题： 加载的时候阻塞网页渲染，引入JS越多，阻塞时间越长。 容易污染全局变量。 js文件存在依赖关系，加载必须有顺序。项目较大时，依赖会错综复杂。 引入的JS文件过多，不美观，且不易于管理。 一、CommonJS规范 CommonJS Modules/1.0规范，服务器端规范。 Node.js推广使用。该规范的核心是：允许模块使用require方法来同步加载所依赖的其他模块，然后通过exports或module.exports导出需要暴露的接口。 特点： 一个模块是一个文件 使用module.exports或exports导出模块 // module.js exports.add = (a, b) => a+b module.exports = { add: (a, b) => a + b } 使用require加载模块 a. require命令第一次加载模块时，执行整个脚本，在内存中生成对象 b. 多次执行require命令再次加载该模块时，不会再执行该脚本，直接从缓存中取值 c. CommonJS加载模块是同步加载模块 Tips： 为什么CommonJS规范不适合作为浏览器的规范 由于CommonJS是同步加模块，在服务端加载模块时都是从本地硬盘中加载，读取速度很快。但是在浏览器端加载模块时

第一章：模块化开发 1.1-模块化概述 1.1.1-为什么需要模块化 传统开发模式的主要问题： 命名冲突 文件依赖 通过模块化解决上述问题： 模块化就是把单独的一个功能封装到一个模块中（文件中），模块化之间互相隔离（高内聚，低耦合），但是可以通过特定的接口公开内部成员（导出），也可依赖别的模块（导入）。 模块化开发的好处，方便代码的重用，提高开发效率，并且便于后期维护。 1.1.2-模块化相关规范 浏览器端模块化规范 AMD，典型代表 Require.js CMD，典型代表 Seajs 在本篇文章中，不做过多解释，因为这两种浏览器端模块化规范已经过时。 服务器端（node）模块化规范 CommonJs规范，在node环境中使用。典型规范定义如下： 模块分为 单文件 与 包 模块成员导出： module.exports 或 exports 模块成员导入： require('模块标识符') ES6模块化规范 ES6模块化规范，是大一统的规范。 在ES6模块化未出现之前，JavaScript社区已经尝试并提出了AMD、CMD、CommonJs等模块规范。 但是这些模块化规范的标准还存在一定的差异性、局限性，并不是浏览器与服务器通用的标准规范。例如： AMD和CMD仅适用于浏览器端模块化规范 CommonJS仅适用于服务器端Node环境 因此，ES6在语言层面上定义了ES6模块化规范

前端在发展，那不是一点快啊，现在的前端项目不再是拼凑几个html页面和写上一堆Jquery就能完成的，web业务正在变得日益复杂，一个Web App的开发难度，类似于开发一个简易型的native app，随之带来了一系列的问题，如何进行高效的多人开发，如何保证优秀的性能，还有如何减少加班时间等等。 前端工程化的内容有哪些？ 模块化 规范化 自动化 组件化 一、模块化 模块化是多人协作的基础。 简单来说，模块化就是将一个大文件拆分成相互依赖的小文件，再进行统一的拼装和加载。只有这样，才有多人协作的可能。 想一想，为什么模块很重要？ 因为有了模块，我们就可以更方便地使用别人的代码，想要什么功能，就加载什么模块。 但是，这样做有一个前提，那就是大家必须以同样的方式编写模块，否则你有你的写法，我有我的写法，岂不是乱了套！ js的模块化 在es6之前，有commonJS，AMD，CMD规范，现在有es6的模块系统 commonJS规范 根据CommonJS规范，一个单独的文件就是一个模块。每一个模块都是一个单独的作用域，也就是说，在一个文件定义的变量（还包括函数和类），都是私有的，对其他文件是不可见的 而且：CommonJS 加载模块是同步的，所以只有加载完成才能执行后面的操作 服务端NodeJS采用了commonJS规范 AMD规范 服务端模块有了，那么客户端模块呢，

对于那些正在构建大型应用程序，而对JavaScript不甚了解的开发者而言，他们最初必须要面对的挑战之一就是如何着手组织代码。起初只要在 <script> 标记之间嵌入几百行代码就能跑起来，不过很快代码就会变得一塌糊涂。而问题是，JavaScript没有为组织代码提供任何明显帮助。从字面上看，C#有 using ，Java有 import ——而JavaScript一无所有。这迫使JavaScript编写者试验不同的约定，并使用现有的语言创建了一些切实可行的方法来组织大型JavaScript应用程序。 各种模式（patterns）、工具（tools）及惯例（practices）会形成现代JavaScript的基础，它们必将来自于语言本身实现之外。 —— Rebecca Murphy 模块模式（The Module Pattern） 用于解决组织代码问题、使用最为广泛的方法之一是 模块模式（Module Pattern） 。我尝试在下面解释一个基本示例，并讨论其若干特性。要想阅读更精彩的说明，并了解用尽各种不同方法的怪人，那么请参阅Ben Cherry的帖子—— JavaScript Module Pattern: In-Depth（深入理解JavaScript模块模式） 。 (function(lab49) { function privateAdder(n1, n2) {

1. 前端模块化 Js模块化提供了三种规范 1，commonjs 规范 代表就是nodejs 适合后台开发 因为是同步的 服务器的运行比较快等待时间不长，commonjs不适合用于前端，前端的客户端是浏览器，浏览器追求异步加载，浏览器不能等待太长时间。 2，前端模块的规范是Amd规范 代表就是requirejs，他是异步的，很多前端框架都是用的amd规范，比如jquery angular等 3，第三个模块化规范是而es6 2.模块化的操作 1.Commonjs的操作 所有的模块化都是两个方向，暴露模块接口和引入模块。 Module.exports={} 暴露的是一个叫exports的对象 Require() 引入一个模块 这是后台的规范，在nodejs环境可以直接运行，但是在客户端不能直接运行，需要对文件打包解析。Webpack gulp 浏览器是一个对象，在 window 对象 　　在 window 中查找 　　方法也是属性，属性值是 function 　　作用域： 　　　　当执行 js 代码时，浏览器会给一个全局环境，叫window，作用域分两部分，一个是内存部分，一个是执行部分，代码从上到下执行，碰到变量， 　　就会在 window 中（内存部分） 查找这个变量是否存在，存在便看赋值了没有，赋值了便是后面的值，没赋值 undefined ， 没声明这个变量 xxx is

模块化的开发方式可以提高代码复用率，方便进行代码的管理。通常一个文件就是一个模块，有自己的作用域，只向外暴露特定的变量和函数。目前流行的js模块化规范有CommonJS、AMD、CMD以及ES6的模块系统。本文主要介绍各规范下的模块化实现方式。 一、CommonJS Node.js是commonJS规范的主要实践者，它有四个重要的环境变量为模块化的实现提供支持：module、exports、require、global。实际使用时，用module.exports定义当前模块对外输出的接口（不推荐直接用exports），用require加载模块。 //定义模块math.js var basicNum = 0; function add(a, b) { return a + b; } module.exports = { //在这里写上需要向外暴露的函数、变量 add: add, basicNum: basicNum } //引用自定义的模块时，参数包含路径，可省略.js var math = require(‘./math‘); math.add(2, 5); //引用核心模块时，不需要带路径 var http = require(‘http‘); http.createService(...).listen(3000); 　　commonJS用同步的方式加载模块。在服务端

基本思路 1. 为什么要做组件化？ 无论前端也好，后端也好，都是整个软件体系的一部分。软件产品也是产品，它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的，在产品目标确定的情况下，成本有两个途径来优化：减少部署成本，提高开发效率。 减少部署成本的方面，业界研究得非常多，比如近几年很流行的“去IOE”，就是很典型的，从一些费用较高的高性能产品迁移到开源的易替换的产品集群，又比如使用Linux + Mono来部署.net应用，避开Windows Server的费用。 提高开发效率这方面，业界研究得更多，主要途径有两点：加快开发速度，减少变更代价。怎样才能加快开发速度呢？如果我们的开发不是重新造轮子，而是 每一次做新产品都可以利用已有的东西，那就会好很多。怎样才能减少变更代价呢？如果我们能够理清模块之间的关系，合理分层，每次变更只需要修改其中某个部 分，甚至不需要修改代码，仅仅是改变配置就可以，那就更好了。 我们先不看软件行业，来看一下制造行业，比如汽车制造业，他们是怎么造汽车的呢？造汽车之前，先设计，把整个汽车分解为不同部件，比如轮子，引擎，车门， 座椅等等，分别生产，最后再组装，所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了，需要送去维修，维修的人也没有在每个地方都修一下，而是只把轮胎 拆下来修修就好了，这个轮胎要是实在坏得厉害，就干脆换上个新的，整个过程不需要很多时间。

文章目录 1-1.浏览器端的模块化问题： 根本原因 解决办法 常见的构建工具 1-2.webpack的安装和使用 webpack简介 webpack的安装 基本使用 1-3.模块化兼容性 同模块化标准 不同模块化标准 最佳实践 1-1.浏览器端的模块化问题： 效率问题：精细的模块划分带来了更多的JS文件，更多的JS文件带来了更多的请求，降低了页面访问效率 兼容性问题：浏览器目前仅支持ES6的模块化标准，并且还存在兼容性问题 工具问题：浏览器不支持npm下载的第三方包 这些仅仅是前端工程化的一个缩影 当开发一个具有规模的程序，你将遇到非常多的非业务问题，这些问题包括：执行效率、兼容性、代码的可维护性可扩展性、团队协作、测试等等等等，我们将这些问题称之为工程问题。工程问题与业务无关，但它深刻的影响到开发进度，如果没有一个好的工具解决这些问题，将使得开发进度变得极其缓慢，同时也让开发者陷入技术的泥潭。 根本原因 思考：上面提到的问题，为什么在node端没有那么明显，反而到了浏览器端变得如此严重呢？ 答：在node端，运行的JS文件在本地，因此可以本地读取文件，它的效率比浏览器远程传输文件高的多 根本原因 ：在浏览器端，开发时态（devtime）和运行时态（runtime）的侧重点不一样 开发时态，devtime： 模块划分越细越好 支持多种模块化标准 支持npm或其他包管理器下载的模块

什么是模块化开发？ 在前端开发中，起初只要在script标签中嵌入几十上百行代码就能实现一些基本的交互效果，后来js得到重视，应用也广泛起来，jQuery，Ajax，Node.js，MVC，MVVM等的助力也使得前端的开发得到重视，也使得前端的项目越来越复杂，然而，javascript却没有为阻止代码提供任何明显的帮助，甚至没有类的概念，更不用说模块化了，那么究竟什么是模块化开发那？ 模块化开发 一个模块是实现特定功能的文件，有了模块，我们就可以更方便的使用别人的代码，想要什么功能，就天津爱什么模块。模块开发需要遵循一定的规范，否则就全乱套了，那么我们就需要使用amd规范，我们根据amd规范，使用defined定义模块，使用require调用模块，目前，通行的js模块规范主要有两种：CommonJS和AMD AMD规范 AMD即Asynchronous Module Definition，中文名是“异步模块定义”的意思，它是一个浏览器模块化开发的规范，服务器端的规范是CommonJS 模块将被异步加载，模块加载不影响后面语句的运行，所有依赖某些模块的语句均放置在回调函数中 AMD是RequiredJS在推广的过程中对模块定义的规范的产生 CommonJS规范 CommonJS是服务器端模块的规范，Node.js采用了这个规范，Node.js首先采用了js模块化的概念

mobile 1，模块===包 　　　 * 传统开发 ，整个网页我们写了一个js文件，所有的特效都写在里面了 　　　　　　　　<script src="js/app.js"></script> 　　　　　　　　缺点：变量容易全局环境 　　　　　　　　　　　　耦合度太高，代码之间的关联性太强，不便于后期的维护 　　　　 * 将一个复杂的js文件 　　　　　　<script src="js/1.js"></script> 　　　　　　<script src="js/2.js"></script> 　　　　　　<script src="js/3.js"></script> 　　　　　　缺点：发生的请求次数过多，依赖模糊，难以维护 　　　　 *使用模块化开发 　　　　　　优点：减少代码之间的关联， 　　　　　　　　　部署方便， 　　　　　　 　　更好的分离， 　　　　　　 　　按需加载， 　　　　　　 　　 避免命名冲突， 　　　　　　 　　容易维护 模块化和传统开发的区别 1， 依赖加载。 　　　　这种方式是最广泛的，像requirejs，sea.js等，除了 编写规范 不一样，实际都是通过相关require api把模块chunk文件拿回来，当加载完成之后再运行逻辑代码。 2， 依赖打包。 　　　　经典代表就是webpack，其实就是写代码的时候分开模块