也来说说webpack
入门
webpack，官方定位是一个模块打包工具，基础命令极其简单
JavaScript
webpack ./entry.js bundle.js
webpack ./entry.jsbundle.js
在CLI模式中，第一个参数是入口文件，第二个参数是输出文件，并读取当前cwd目录下面的 webpack.config.js 配置，根据配置生成对应的bundle.js文件。
其用法与RequireJS里面的r.js命令极其相似。
快速上手
如果一个新业务，想做一下JS的模块化管理，那么可以立即选择webpack了。
如果一个老业务，曾经用了RequireJS或者SeaJS，那么也可以选择切换webpack了。
如果想做一个库/框架去为生态提供服务，也可以立即选择webpack，他能自动配置最终生成的library.js文件支持AMD/CommonJS等模块化方案。
用好配置里面的 resolve ，改造一下原有的Grunt/Gulp流程，即可使用webpack，业务代码基本无需改造。
多种模块化打包加载方案对比： http://webpack.github.io/docs/comparison.html 。
其实对于老业务而已，仅仅将JS的模块化从RequireJS替换到webpack，其收益并不明显，仅仅是最后生成的JS文件要小一些而已。
进阶
如果单单从CLI模式中的提供的参数来看，webpack的能力也就到此为止了。但webpack的作者并非只想做一个AMD/CommonJS/ES6 Modules的协议实现。
webpack提供了一个Loader和Plugin的机制，让社区通过提交自己的Loader和Plugin，大大拓展了webpack的应用场景。
别忘了，webpack的REPL可是完整的nodejs，也就是说Grunt、Gulp能做的事情，webpack也能做（只是能做，不代表webpack擅长做）。
同时，通过各种Loader和Plugin，webpack还能打包样式、图片等资源文件，并按需将这些资源文件inline到html中。
与babel的勾搭
建议es-2015就先别折腾了，webpack本身编译速度，在我的MBP上面是50ms上下，但加入babel并使用es-2015语法转换后，编译耗时直接涨到700~800ms，这还仅仅是只有两个js文件的demo。
在webpack的roadmap里面，看到有对ES6 Modules进行支持的计划，我们还是静等吧。
欠成熟的Loader和Plugin列表
其最富有想象力、最能拓展的Loader和Plugin，她们的列表是竟然是人工维护的一份Github Pages。相对于其他社区来说，这块差了点。同时由于是手动维护的列表，其Loader和Plugin的质量，只能通过Github和npm中进行判断。
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
