摘要：前言前端模块化，主要是解决两个问题命名空间冲突，文件依赖管理。目前解决的方法是模块化命名空间各个模块的命名空间独立。模块化构建工具，等是用来组织前端模块的构建工具加载器。
前言
前端模块化，主要是解决两个问题——“命名空间冲突”，“文件依赖管理”。
坑___命名空间冲突
我自己测试好的代码和大家合并后怎么起冲突了？
页面脚本的变量或函数覆盖了公有脚本的。
坑___文件依赖管理
明明项目需要引入的包都引进来了怎么还报缺少包？
手动管理依赖，有天要更换某个插件，要深入代码内部进行修改
如下图，显示的代码加载，依赖关系复杂。在F.js中，分不清某个变量是来自C.js，还是E.js
两次加载同一个模块。比如引入了两遍JQ
其他的坑
为了实现脚本复用，将一个很大的公用public文件引入各个页面中，其中的某些函数，只有个别页面用到。
某个功能的函数群函数，与另一个功能的函数群摆在一起，使用注释来分隔。
目前解决的方法是:模块化
命名空间：各个模块的命名空间独立。A模块的变量x不会覆盖B模块的变量x。
模块的依赖关系:通过模块管理工具如webpack/requireJS/browserify等进行管理。
模块化的基本原理——解决命名空间冲突JavaScript的缺陷，首当其冲就是全局变量。这使得每想命名一个变量的时候都要三思又三思，生怕上方无穷远的地方有一个同事些的代码和自己冲突。以下是一些防范方法
一、使用命名空间
代码如下：
//定义
var module = {
name: "rouwan",
sayName:function(){
console.log(this.name)
}
}
//使用
var a = module.name;
console.log(a)
总结：直接修改name不会影响module.name，一定程度保护了命名空间。有两个缺点，一，外部还是可以修改module的属性和方法。二，命名空间有时长起来超乎你的想象。适合一些小型的封装，如一些配置。
二、立即执行函数 + 闭包（实现模块的基本方法）
立即函数可以创建作用域，闭包则可以形成私有变量和函数
//创建
var module = (function(){
var privateName = "inner"; //私有变量
var privateFunc = function(){ //私有函数
console.log("私有函数")
}
return {
name: "rouwan", //公有属性
sayName:function(){ //公有函数
console.log(this.name)
}
}
})()
//使用
module.sayName(); //"rouwan"
总结：这是目前比较常用的模块定义方式，可以区分私有成员和公有成员。公有变量和方法，和之前一样可以直接通过module.name的方式修改。私有变量和方法，是无法访问的，除非给你个修改私有成员的公有方法。
三、在上述基础上，引入其他模块
//定义
var module1 = (function(mod){
var privateName = "inner1";
var privateFunc = function(){
console.log("私有函数1")
}
return {
name : "rouwan1",
sayName: function(){
console.log(this.name)
},
anotherName:mod.name, //另一个模块上的公有参数
sayAnotherName:mod.sayName //另一个模块上的公有方法
}
})(anotherModule) //引入了另一个模块
//使用
module1.sayOtherName()
总结：在一个模块中可以引入另一个模块。
四、其他的方式
放大模式等是以往用来管理大型模块，进行文件拆分的方法。现在webpack等模块化工具都很完善的情况下，已经显得有点落后了。就不介绍了。
我了解js模块是从立即执行函数开始的。但是等到真正使用构建工具的时候，却发现业界采用的模块化方案，却并非是一个一个由立即函数+闭包形成的集群。
而是用了诸如AMD/CMD/CommonJS/ES6模块等等模块化实现。
这里面的原因可能有这几个，一，闭包的性能问题。二，当模块增多的时候，需要解决模块间的依赖管理问题。
关于依赖管理，目前项目里碰到了几个不舒服的地方：
仅此一图，无须多言
HTML中引入了两遍的jq，导致脚本报错。
有一个公用脚本，包含了N多的公用模块。有些页面明明只用到了一个模块，也必须全部加载一遍。
因此，必须使用模块化管理工具!
几个概念
包管理工具: 安装、卸载、更新、查看、搜索、发布包。比如你需要安装个jq等，通过npm来安装。npm里有依赖管理，假如jq或者说express升级了，原来代码不能用了。帮助你解决这个问题的就是npm。
模块化构建工具：webpack/requireJS/seaJS，等是用来组织前端模块的构建工具（加载器）。通过使用模块化规范（AMD/CMD/CommonJS/es6）的语法来实现按需加载。举个栗子，如果有一天你不用维护一个很长很长的公用脚本文件，这得感谢它。
模块化规范：：AMD/CMD/CommonJS/es6模块等等规范，规范了如何来组织你的代码。一般这种方式写的代码浏览器不认，需要用模块化构建工具来打包编译成浏览器可以识别的文件。
从我的表格里，可以看出我的推荐搭配———— npm +webpack + es6模块。
理由如下：
npm与bower比较：
原来bower的使用优势就是适合前端模块管理，而npm被视为只适合后端的管理。但是随着webpack的流行，这个已经毫无疑问是npm胜出了。npm+webpack，可以实现良好的前端模块管理。
webpack和requireJS比较：
几种模块化规范比较：
所以就决定是你了！ npm + webpack + es6模块。
入门实践在我的另一篇文章 npm + webpack + es6 初体验
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/80432.html
摘要：纯前端开发主要是针对静态页面。自主权最大，正常是使用进行辅助开发，上线等。大致原因使用是为了和端的保持同步。四总结对于比较正式的项目，前端技术选型策略一定是产品收益最大化，用户在首位。 对于前端团队，可以实现企业受益最大化要点。 一、技术选型的策略 1、保证产品质量 （1）功能稳健：网页不白屏，不错位，不卡死；操作正常；数据精准。 （2）体验优秀：加载体验，交互体验，视觉体验，无障碍访...
摘要：前端准备前端了解过关了吗前端基础架构和硬核介绍技术栈的选择首先我们构建前端架构需要对前端生态圈有一切了解，并且最好带有一定的技术前瞻性，好的技术架构可能日后会方便的扩展，减少重构的次数，即使重构也不需要大动干戈，我通常选型技术栈会参考以下三 # 前端准备 ：前端了解过关了吗？前端基础架构和硬核介绍 showImg(https://segmentfault.com/img/remote/...
摘要：前端准备前端了解过关了吗前端基础架构和硬核介绍技术栈的选择首先我们构建前端架构需要对前端生态圈有一切了解，并且最好带有一定的技术前瞻性，好的技术架构可能日后会方便的扩展，减少重构的次数，即使重构也不需要大动干戈，我通常选型技术栈会参考以下三 # 前端准备 ：前端了解过关了吗？前端基础架构和硬核介绍 showImg(https://segmentfault.com/img/remote/...
摘要：前端准备前端了解过关了吗前端基础架构和硬核介绍技术栈的选择首先我们构建前端架构需要对前端生态圈有一切了解，并且最好带有一定的技术前瞻性，好的技术架构可能日后会方便的扩展，减少重构的次数，即使重构也不需要大动干戈，我通常选型技术栈会参考以下三 # 前端准备 ：前端了解过关了吗？前端基础架构和硬核介绍 showImg(https://segmentfault.com/img/remote/...
摘要：公司的招聘要求都提到了至少熟悉其中一种前端框架，有前端工程化与模块化开发实践经验相关字眼。我们主要从端公众号移动端小程序三大平台进行前端的技术选型，并来说说选其技术的几大优势。技术的优势互联网前端大潮后，前端出现了大框架，分别是与。 1、技术选型的背景前端技术发展日新月异，互联网上出现的新型框架也比较多，如何让新招聘的人员...
阅读 2998·2021-11-18 10:07
阅读 3740·2021-11-17 17:00
阅读 2066·2021-11-15 18:01
阅读 909·2021-10-11 10:58
阅读 3308·2021-09-10 10:50
阅读 3394·2021-08-13 15:05
阅读 1209·2019-08-30 15:53
阅读 2618·2019-08-29 13:01
