边界: 自动化打包,编译,解决真正web开发之前遇到的各种兼容,性能,环境,效率…等开发中需要处理,却又与真正的业务代码开发无关的开发前置问题

如何在浏览器实现模块化

问题:

• 效率问题: 精细模块划分带了个很多的js问题,很多的js文件带来了更多请求,降低了页面的访问效率
• 兼容性问题: 浏览器目前不支持ES6的模块化标准,并且还存在兼容性问题(浏览器不支持commanJs)
• 工具问题: 浏览器不支持npm下载的第三包(不支持直接引入node_modules)

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

根本原因

思考: 上面 提到的问题,为什么在node端没有那么明显,反而到了浏览器端变得如此严重?

在node端,运行的js文件在本地,因此可以读取本地文件,它的效率比浏览器远程传输文件高的多

根本愿因:

在浏览器端,开发时态(deytime)和运行时态(runtime)的侧重点不一样

开发时态,devtime

1. 模块划分越细越好
2. 支持多种模块化标准
3. 支持npm或者其他的包管理器下载的模块

4. 能够解决其他的工程化问题

   运行时态

5. 文件越少越好,

6. 文件体积越小越好
7. 代码内容越乱越好
8. 所有浏览器都要兼容
9. 能够解决运行时态的其它问题,主要是执行效率的问题

这种差异在小项目中表现的不明显,可是一旦项目形成规模,就越来越明显,如果不接觉这样的问题,前端项目形成规模只是空谈

解决办法

既然开发时态和运行时态面临的局面有巨大的变话,因此,我们需要一个工具,这个工具能够帮助我们让开发者专心在开发时态写代码,然后利用这个工具将开发时态的代码转换为运行时态需要的东西

这样的工具,叫做构建工具

这样一来,开发者就可以专注开发时态的代码结构,而不用担心运行时态遇到的问题

常见的构建工具

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