为何学过模块化这里还要学习模块化,因为之前的都是小打小闹的项目,不会在意那吗多,如果是一个完整项目他会多少个模块化的js文件,如果都将其导入那会发起多少个请求,这吗多请求会导致页面的效率问题。其他问题如下

浏览器的模块化

浏览器模块化的问题:
效率问题:精细的模块划分带来了更多的JS文件,更多的JS文件带来了更多的请求,降低了页面访问效率
兼容性问题:浏览器目前仅支持ES6的模块化标准,并且还存在兼容性问题 (jQuery 需要通过CommonJS 导入,可浏览器只支持es6的模块化标椎,那就无法导入)
工具问题:浏览器不支持npm下载的第三方包
兼容性问题如下
image.png
上图是jQuery的包,可以看出他的导出方式是CommonJS的导出方式
当我们在浏览器中导入jQuery的包,会报如下错误显示导入方式必须为”/“ “./“ 和 “../“
image.png
且jQuery的包是通过npm安装的,那吗引入方式如下

  1. // import *as jq from "jquery"; // 无法引入
  2. const jq = require("jquery") // 可以引入
  3. console.log(jq)

这些仅仅是前端工程化的一个缩影
当开发一个具有规模的程序,你将遇到非常多的非业务问题,这些问题包括:执行效率、兼容性、代码的可维护性可扩展性、团队协作、测试等等等等,我们将这些问题称之为工程问题。工程问题与业务无关,但它深刻的影响到开发进度,如果没有一个好的工具解决这些问题,将使得开发进度变得极其缓慢,同时也让开发者陷入技术的泥潭。

根本原因

上面的问题,在node端没这吗明显,反而到啦浏览器端变的很严重
因为的node运行的文件本地,因此可以读取本地文件,它的效率比浏览器远程传输文件高的多
根本原因:在浏览器端,开发时态(devtime)和运行时态(runtime)的侧重点不一样
开发时态:devtime:
模块划分越细越好
支持多种模块化标准
支持npm或其他包管理器下载的模块
能够解决其他工程化的问题

运行时态,runtime:
1:文件越少越好
2:文件体积越小越好
3:代码内容越乱越好
4:所有浏览器都要兼容
5:能够解决其他运行时的问题,主要是执行效率问题
第一条文件越少越好是因为js文件都是一部请过来的,模块化后会把工程分的很细,那就让页面请求很多js文件故越少越好,第二条,在开发时注重代码越规范越好,就不会注重文件体积,可是里面的空格也是占用文件体积的,这也是为啥有些网站上的js代码都是一坨的,还只有一行,第三条是防止别人将其源码复制下来,第四就是兼容性问题
这种差异在小项目中表现的并不明显,可是一旦项目形成规模,就越来越明显,如果不解决这些问题,前端项目形成规模只能是空谈

解决办法

既然开发时态和运行时态面临的局面有巨大的差异,因此,我们需要有一个工具,这个工具能够让开发者专心的在开发时态写代码,然后利用这个工具将开发时态编写的代码转换为运行时态需要的东西。
这样的工具,叫做构建工具
image.png
这样一来,开发者就可以专注于开发时态的代码结构,而不用担心运行时态遇到的问题了
这也是为啥需要构建工具啦

常见的构建工具

  • webpack
  • grunt
  • gulp
  • browserify
  • fis
  • 其他