模块化开发简述

模块化开发简述

都说模块化开发为前端发展带来了巨大的进步,然而不熟悉的人看着也是两眼一懵,那其实这到底是什么?好处在哪?我来说说自己的见解吧。
这里写图片描述
1. 模块化和传统开发的区别
实话讲,其实在我看来,两者的开发是一样的,除了方式不一样,达到的效果并没两样。
看着扯淡,但实际可以想一下,现流行的模块化开发主要有两种方式:

  • 依赖加载。这种方式是最广泛的,像requirejs,sea.js等,除了 编写规范 不一样,实际都是通过相关require api把模块chunk文件拿回来,当加载完成之后再运行逻辑代码。
  • 依赖打包。经典代表就是webpack,其实就是写代码的时候分开模块,但打包的时候按依赖关系找到各个模块,最后打包到同一个文件上,并给每个chunk标识id,运行逻辑代码时将模块引用指向该id,从而实现模块化。

而传统的开发方式是在页面上通过脚本标签引入,等所有脚本资源加载完成后再运行逻辑代码。这样一对比,是不是发现效果其实是一样的,我把不同脚本分开写,也是可以做到类似模块化的效果?

那么重点来了,模块化的优势在哪?

别急着回答,先思考一下,然后带着你的想法继续看下去。

这里写图片描述

先回想一下,传统开发的痛点在哪。

首先,如上所述,传统的开发方式需要等待所有脚本资源加载完成。这个问题最大的弊端就是页面要等待,因为资源加载是同步的。你的页面会出现短暂的空白期,引入的脚本越多,时间越长,如果某一脚本加载失败,也可能直接挂掉。

模块化的代码则可以很好的处理这个问题。除了模块化支持的脚本必须加载进来以外,其他脚本都可以异步请求,不需要页面等待,可以加速渲染出页面。requirejs,sea.js等也会做好加载重试和模块缓存的处理,确保所有模块运行良好。

所有资源加载的时间不会因为模块化而加速,但是模块化能加速渲染,这是优势1

当然webpack是特例,它和nodejs一样用 commonjs 规范,为了达到目的,全部脚本打包到一起再运行,看着和上面观点相悖,不过现在带宽足够,相对而言还是足够快的,也能减少多脚本加载出错的风险。


接着上面的观点讲,抛开带宽速度来讲,既然网速够快,那模块化还有什么?不妨回想一下,传统开发时最烦的是什么?无非3点

  • 命名空间。早期为了避免命名冲突,大众做法是用一个变量作为命名空间做隔离,长期开发过程中没人能记住这个变量是否冲突,它的命名规范是什么,治标不治本。
    而模块化的出现消除了这点。一个模块内的命名随自己起,和外界不会冲突,对外的永远是你exports出来的内容。如果模块内出现命名冲突,这说明了你的命名水平太低…..
    这里写图片描述
    好吧,是模块颗粒不够小,还可以继续分割出模块~

  • 代码重用。其实这点和传统开发并无两样,都是把可复用代码抽取出function(再通用点会抽象出类,也就是构造函数),独立文件。但模块化的好处同样可以规避命名空间的问题,不必设置变量污染到全局。一般模块化都有缓存机制,在二次调用时无需再解析,直接获取到缓存模块内容。

  • 懒~ 这里写图片描述
    按传统开发来处理,忽略以上问题,但也耐不住文件太多,引入和管理麻烦。除了amd规范需要依赖前置,我们还可以用cmd规范来写模块依赖,想用什么require什么,不用再一个个引入js,看着也舒服。而且现在的模块化工具基本都实现了多规范混搭,想怎么写就怎么写,只要注意组内规范就行。



此外就是 管理问题

小公司或个人开发,模块化能让自己思路更为清晰,降低代码耦合,优秀的模块能带来代码质量质的飞跃,标准的模块应该是 “分工明细,职责单一,不牵扯需求逻辑” ,它就应该是个万能的螺丝,不需要可以修改,哪里需要用哪里。

而中型企业和大团队则很经常会遇到团队协作开发,除了会用svn/git等工具管理,各种需求有不同的人负责处理。模块化对团队开发会起到协同作用,公共模块除了避免重复造轮子的痛苦外,也避免了逻辑混淆。



好了,大概就上面这些,我现阶段的水平限制了我的眼界和理解,后面有不一样的看法时再修正补充吧。
这里写图片描述

你可能感兴趣的:(model,webpack,requireJS,amd,commonJS)