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中。

基本使用

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

上一篇下一篇

猜你喜欢

热点阅读