webpack, javascript module bundler. generates static assets representing those modules. 现存的模块处理工具不满足大项目(大的单页面项目),为什么要重复造轮子最值得说的就是代码分割,项目的代码按照模块来开发处理, 同样最终的静态文件也是要能够无缝进行模块化.
目的
- 能够把现有的依赖树整个切分按需加载
- 能够保证初始化加载的代码里很小, 很快
- 静态资源同样能够模块化
- 能够轻松地把第三份库作为模块加载
- 能够很容易自定义这个模块处理工具的每一个部分.
- 适合大项目.
webpack 有什么不同:
- 代码分割
webpack 定义了2种不同的依赖树,同步的和异步的. 异步的依赖作为一个切割点, 然后单独存在, 共享这个块.
- 加载器
webpack 只能处理 javascript, 但是通过 loader 可以处理各种资源转换为 javascript, 这样就能够处理任何形式的模块.
- 智能解析
webpack 可以智能解析各种第三方的库, 它甚至可以允许用表达式来书写依赖. 如` require("./templates/" + name + ".jade"). 它支持常见的模块风格( CommonJS 或者 AMD)
-插件系统
webpack 拥有丰富的插件系统. 大部分内部的功能都是基于这个插件系统的. 这个就允许你可以更加自由的自定义它本身已经各种第三方需求.
webpack 产生的动机
现如今的网页有以下的发展趋势:
- 越来越多的使用 javascript
- 越来越多的使用现代浏览器
- 更少的重载整个页面->一个页面的代码越来越多.
结果就是客户端承载了很多的代码. 面对的问题就是如何组织这些代码, 模块化就应用而生了.
模块化系统
有很多的标准用来定义依赖和声明变量
- 原始的
<script>
这个是最原始的方法了, 并没有借助任何的工具,只是人为的给定义到不同的 js 文件里, 然后手动去管理加载的顺序来处理依赖和冲突. 时间久了就没有人知道什么是什么了.
- CommonJS
这个是通过同步的
require来完成单独的模块,然后以模块的形式暴露出去使用. 通常在nodejs中使用.
优点:
- 这样定义的模块虽然内部是同步加载的但是它可以缓存重用.
- 有很多现有的东西拿来就能用
- 简单上手
缺点:- 网络传输是异步的
- 不能够并行加载模块
- AMD
相对于 CommonJS 的同步加载,它解决了异步加载的问题, 但是同样有很多问题
优点:
- 异步加载
- 并行加载多模块
缺点:
- 难懂
- 复杂等
- ES6 模块
想法很好,已经很为标准,但是浏览器落实需要时间 ...
-
更多..
-
中立的方法:
保留现有的风格, 然后添加自定义的模块风格进去.
传输
模块总归还是要在客户端执行,就需要从服务器传输到浏览器.
有2个极端:
- 一个模块一个请求
- 所有模块一次请求拉下来
都可以,但是都不完美
一个请求一个模块
- 优点:指搂需要的
- 缺点:请求多就意味着过载
- 缺点:慢,越来越慢
所有请求一次来
- 优点:减少请求次数
- 不用的也要 down 下来
块形式传输
来一个灵活的方式,折中的.
- 当我们在编译模块的时候,分割代码到块
减少每次请求的数据量, 按需加载模块. 工程师定义分割点.
灵感来源于 google 的 GWT
为什么只支持 javascript 呢?
为什么只支持 javascript 呢, web 有很多东西需要处理的
- css
- image
- webfonts
- html template
- etc
或者需要转换的
- coffeescript
- elm
- less stylesheets
- jade template
- etc
其他他们直接 require('..') 就可以了
静态分析
当编译这些模块的时候,静态分析用来处理之间的依赖.
ref: