webpack 入门
说一点历史，为啥这次说历史，因为知道这个历史是有用的，不像那些没用的历史，知道过去能够更好的预测未来。
1.最开始我们写代码
<script src="xxxx"></script>
问题：变量冲突，只能顺序加载，无法解决相互依赖，时间长了混乱不堪。
2.IIFES
匿名函数多了依然管理起来麻烦，混乱。
3.面向对象
这个方式不错，就是有些复杂另外依然存在冲突隐患，比如命名空间。
4.commonjs
nodejs的模块系统实现方式：
require("module");
requeri("./file.js");
exports.doStuff = function() {};
module.exports = someValue;
优点是简单重用，缺点是尼玛呀，前端不用考虑异步么？总不能一个模块卡那里，别人都傻等着吧。
5.AMD
require.js实现方式，
define("module", ["dep1", "dep2"], function(d1, d2) {
return someExportedValue;
});
require(["module", "../file"], function(module, file) { /* ... */ });
优点异步，缺点尼玛呀这么一大坨代码我就想写个alert费死劲了。各种回调，难受死了。
6.CMD
对，你没有看错，就是CMD,跟common不是一码事。
seajs实现方式，
优点是异步，你能在node里面玩，缺点是越来越特么的复杂了。
7.ES6模块
ES6 模块
这个是原生的不需要什么库，当然你可以去看看Babel。
在ECMAScript2015(es6)中，增加了JavaScript语言层面上的模块体系定义，其设计思想是：尽量的静态化，使得编译时就能确定模块的依赖关系，以及输入和输出变量。
import "jquery";
export function doStuff() {}
module "localModule" {}
缺点：
我只是一个前端，搞这么复杂我只是想写个选项卡，你让配置那么多东西，调各种模块合适么？
1.复杂，尤其是对小白
2.逻辑过重，向后台靠拢，还不兼容。
优点：
容易进行静态分析
面向未来的 EcmaScript 标准
可以把所有东西模块化
但是，可是，可但是，但可是，必须有问题，否则就我没法往下讲了，也是webpack出现的一个理由
把程序所有的文件进行模块化之后，我们还要处理一个问题那就是传输问题。模块的化分让我们可以让程序变得可以组件化进行开发，组件虽然被客户端执行，但是依然要由服务器传送给客户端。==
关于组件的传送有两个极端：
每个组件，一个HTTP请求
优点：仅仅传送依赖项
缺点：请求多，负载高，更慢的启动延迟
所有的组件，一个HTTP请求
优点： 更快，更低的延迟
传送了没有必要传送的东西
让我在这两种情况之间做一个妥协：分块传输，按需进行懒加载，在实际用某些模块的时候进行增量的更新，才是比较合理的加载方案。
要实现这个功能，需要在编译打包时进行静态的分析、模块进行分批次的打包。那么这个分批次谁来做呢？
答案就是：==WebPack==bpack是啥？
一句话，它其实严格的说更像gulp，虽然官方声称是模块加载和打包工具，个人使用感受是，用模块化的方式写任务，
当然了撸代码确实更爽，特别强调一句，这货把各种资源都给模块化了，比如图片等。
要学会wb（webpack），必须懂四个东西：
入口 一条蛇钻进了河里 （输入什么东西）
出口 出来一只王八（输出什么东西）
加载器 大象一把踩上去（遇到什么样的文件，用什么解析，比如.less文件的加载器是less）
插件 小样你把马甲穿上照样认识你！（加载器是文件级别的，插件可以文件级别也可以函数级别更精准的控制）
总结一句话，webpack就是帮你把所有资源全部模块化的一个工具，具体的四个概念和详细的代码，我们下篇继续。
网友评论