webpack 解决的痛点

webpack

webpack -模块化加载器，同时支持amd，cmd等加载规范。

---

1、AMD模块规范开发，使用requirejs实现，使用rjs打包，最终导致的结果是，输出的项目臃肿，
肿的就像一坨狗不理……不忍直视
2、使用gulp进行打包，这一点貌似没有可吐槽的地方，毕竟都是被grunt折磨过来的……
3、数据的渲染使用模板引擎，这就意味着你要手动管理DOM，这样，你的业务代码参杂着
你的数据处理、DOM管理，满屏幕的毛线……
4、模块化不足，虽然使用require进行了模块管理，但是大部分业务逻辑还是充斥在一个文
件里，这与最近流行的组件化概念冰火不容，拒绝落后……
5、诸如 扩展性 、 维护性 我想早已不言而喻，不需赘述，再述就真TM是累赘了。

---

要解决的问题
1、要使构建输出的项目像你邻家小妹妹一样、瘦的皮包骨。
2、要实现真正的模块化、组件化的开发方式，真正去解决维护难、扩展难的问题。
（从此不怕产品汪）
3、业务逻辑专注数据处理，手动管理DOM的年代就像……像什么呢？
（毕竟成人用品也越来越自动化了）

解决方案tips

---

1. 为什么老项目构建臃肿不堪？
    基于requirejs进行打包，会把项目所有的一来都打包到一个文件里，如果项目中同时依赖一个模块，
rjs 并不能提取为公共模块。使用webpack配合响应loader，来完成加载和构建。

2.老项目为什么模块化不足？
    老项目的模块化，仅仅体现在js层面，解决了模块引用的问题，但在开发方式上，依然可以
看做是过程式的， 这样的结果就导致了项目的难扩展和难维护，让开发人员在与产品汪的对峙中，并不从容。

3、如何避免手动管理DOM？
    如果你在做数据展示这一块的开发工作，相信你一定体会颇深，发送http请求到服务端，
拿到返回的数据后手动渲染DOM至页面，这是最原始的开发方式，无非再加一个模板引擎之类的，
但最终还是避免不了手动渲染，如果页面逻辑复杂，比如给你来一个翻页的功能，再来一个筛选项，
估计你会觉得世界并不那么美好。

webpack 优势

---

1.代码分割：
  webpack支持二种依赖加载：同步和异步。同步的依赖会在编译时直接打包输出到目的文件。异步加载会单
独生成代码块，只有在浏览器中需要时才会异步加载这些代码块。
2.Loaders：
  默认加载js，通过loaders来把其他类型的资源转换成js输出。
3.各种插件
  webpack提供强大插件来提高工作效率。

安装

---

全局安装

npm i webpack -g

局部安装

同样也可以在项目中安装。
此时，应该先初始化npm项目

npm init
npm i webpack -save-dev

此时会写入到package.json中。

基本使用

——————待续-----