webpack 解决的痛点
2016-10-31 本文已影响0人
dulei_fe
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中。
基本使用
——————待续-----