《深入浅出webpack》有感.docx

《《深入浅出webpack》有感.docx》由会员分享，可在线阅读，更多相关《《深入浅出webpack》有感.docx（8页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、对于前端仔来说，相信大家对webpack都再熟悉不过了，但是你对webpack的了解程度又有多深呢，笔者花了几天时间看了一下深入浅出webpack，虽然说书中大局部介绍的是配置和使用相关的，但是如果你对webpack的配置、使用、原理和构建流程 更加熟悉的话，对于你的开发可以说是百里无一害！本文不会局限 于介绍配置，也不会详细介绍打包原理（后面打算写一篇有关webpack打包原理的），更多着重于webpack打包的思想介绍。没有打包构建的日子nodejs的出现对于构建工具具有重要的意义，在没有nodejs之前，js只能执行 在浏览器环境下，所以意味着对发布前的js文件要进行处理，十分局限，没有

2、 打包工具，只能用PHP脚本来处理文件，甚至还需要借助一些在线压缩网站， 开发体验十分差劲，在史前时代存在以下几个痛点：1、缺乏文件处理工具，对文件进行编译或其他预处理，进行打包压缩等工作；2、缺乏文件的模块化，引入第三方库直接用cdn引入，需要处理依赖管理，人 为控制脚本的加载顺序，并且存在全局变量命名冲突的问题；3、缺乏代码校验和自动化测试，在代码被提交到仓库前需要校验代码是否符合 规范，以及单元测试是否通过。有了打包构建工具的日子随着nodejs的诞生，我们可以在开发环境下书写nodejs代码脚本，对我们的前 端代码做预处理，编译压缩等工作，最初诞生的是grunt和gulp, Grunt

3、和Gulp 都属于任务流工具Tast Runner,两者都是通过配置好配置文件，但是相比之下， gulp通过函数式编写配置文件，以及前端人员所熟悉的链式调用，让大家觉得更易懂更易上手，gulp本身借鉴了 grunt的经验进行升级和加入一些新特性。正因为流管理多任务配置输出方式的提高,人们逐渐选择使用Gulp而放弃grunto有了 grunt和gulp,文件压缩处理的工作解决了，代码校验和测试也可以处理 了，但是模块化仍没有结果？其实前端的痛点还远不止模块化那么简单，频繁的DOM节点处理，JS里杂糅了交互逻辑、请求逻辑、数据处理和校验逻辑、DOM操作逻辑，导致JQ书写的 代码就更意大利炒大便，呸

4、！意大利炒面一样。在团队开发中，可能你的代码要 给别人维护，这就非常痛苦了。webpack诞生记工、模块化思想隔离不同的js文件，模块化开发，仅暴露当前模块所需要的其他模块，这是模 块化思想想要传递给我们的。nodejs诞生后，后端所采取的模块化思想是 commonjs,然而，不同于后端，前端的代码运行在浏览器端，有两点不同之处:1、没有nodejs执行环境，不支持module.exports的书写格式；2、后端require一个文件，是读取本地文件的形式，速度极快，而对于前端而 言，需要去动态加载一个js文件，存在额外耗时。于是AMD思想应运而生,对此的相应实现是requireJS,允许你定

5、义好模块名称、模块依赖以及当前的模块代码(function),通过广度优先遍历的方式，递归加 载父模块所依赖的子模块，但是这也暴露出了一些问题：1、通过js加载执行后再去加载其依赖的子模块，这个递归加载过程本身是耗时 的；2、模块化思想提倡我们分隔逻辑，管理好各个js文件内的逻辑，一旦分割的JS 文件过多，最终造成前端资源加载压力。不过不用担忧，requires提供了 rjs来处理发布前的模块合成，帮助你把多个 JS文件打包成一个文件。再到后来，国内出现了 CMD的思想，不同于AMD的声明依赖的形式，允许你 动态加载依赖，但是其实现以及具体的运行结果被大家诟病。再到后后来，为了解决这种不同库的

6、模块实现不一致的问题，提出了 UMD,其 实很简单，只是写一段hack,让你的模块能够兼容不同的模块加载场景，无论 是commonjs还是AMD,如果都没有的话就直接声明为一个全局变量的形式。下面引用一段UMD的代码：(fuictioi (global, factory) tgpcof exports = object1 & typeof module != filled1 ? iodule.exports 二facto丫g。:typeof define = fix八ctio八& define。md ? deffactory):(global = global | self, global.V

7、ue = factoryQ);fiAictioi 0 tse strict1;/your code here 再到后后后来，未来的大一统，es6中所提出的import和export的形式来统一 前后端的模块化加载方式。相比以往的实现，import/export的形式，在模块化 加载JS文件的时候，保存动态的执行引用，其次，不允许动态控制加载依赖， 使得tree-shaking成为可能。2、组件化思想组件化的思想并非前端所特有，在客户端也会面临相同的问题。想象一下，A跟 B被同时分配一起开发完成一个首页页面，包括导航栏、轮播图、网站列表数据， 登录框等，两人需要如何分工协作？导航栏、列表这种需要

8、在多个页面复用的 HTML怎么办？假如在没有组件化处理的情况下：1、A和B分工困难麻烦，代码提交时会处理大量的冲突；2、导航栏、列表等多处复用的地方，需要cv大法直接复制粘贴到另一个页面中 去使用。组件化思想，让我们把页面划分为一个个组件，组件内部维护自己的UI展示、 交互逻辑，组件间可以进行数据通信，实现一种变相的相互隔离，便不会出现A 和B两人一起编辑一段html的难受场景，同时，提高了代码的可维护性和复用 性，这是其解决的关键痛点。引用vue官网的一张有关组件化思想的图：3、MVC框架、MVVM框架的流行在模块化和组件化的基础上，实现了页面组件之间的隔离和各自维护，但是面临 的最大的一个

9、痛点问题，仍然是前面所说的，前端的JS逻辑中杂糅了各种处理逻辑，交互逻辑、请求逻辑、数据处理和校验逻辑、DOM操作逻辑；而其实这 一切可以划分为两个层次，一个是数据层，一个是视图层，如何防止重复的书写 操作DOM的逻辑，如果说早期的各种模板引擎给了我们初期的解决方案，那么vue react以及angular就是在模板引擎的基础上的上层建筑。为了让我们更加专注于数据的处理，MVC框架和MVVM框架帮我们做了以下两 件事：1、监听页面操作事件，触发相应的事件钩子，执行代码逻辑，即V层到M层的 过程；2、执行代码逻辑后，数据层发生修改，帮我们更新渲染页面，即M层到V层的过程；vue中通过vm实现，r

10、eact中通过触发setState通知。如此，我们只需要书写一次html,在html中写明绑定或展示的数据，同时绑定 好事件监听器，后续便不需要再处理视图层相关的操作，只需要关注于自己的业 务逻辑代码、数据层的处理等。MVVM架构流程图:MVVMDOMDOMDOMViewPlain JavaSci ObjectsVue4、代码打包构建前面介绍了 grunt、gulp打包构建工具，其实webpack本质也是打包构建工具， 但是webpack呈现出来的功能更为强大和成熟。对于代码的预处理、模块化加 载、代码分割等，webpack具有更大的优势。webpack 诞生!rL nLmoduleswith

11、 dependencieswebpackMODULE BUNDLERstatic assets读者读到这里，可能仍有些许疑惑，前面讲了这么多，为啥还是没有介绍到 webpack相关的，其实不然，仔细回想一下前面所介绍的思想，以及你平时使用webpack来打包构建的时候，其实webpack正是帮你处理了这些繁杂琐碎的 事情。如果代码预处理压缩足以，那么grunt和gulp已经满足了；如果说模块化开发足以，那么requireJS和Browserify已经满足了；如果说组件化开发、MV*框架足以，那么只需要在页面内引入相应的vue或react框架，足矣。笔者写这边文章，更多是想让大家能够思考工具或者

12、框架背后，所呈现出来的思 想，webpack就像是一个巨无霸，集大成者，它解决了打包构建，它处理了模块化开发，它帮助你和其他框架完美融合实现组件化开发；而这几年来MV*框架的流行对于webpack市场的迅速扩展有着不小的贡献。webpack为我们做了以下这些事：（引自深入浅出webpack） 代码转换:TypeScript编译成JavaScript SCSS编译成CSS等。 文件优化：压缩JavaScript. CSS、HTML代码，压缩合并图片等。代码分割：提取多个页面的公共代码、提取首屏不需要执行局部的代码让其异步 加载。模块合并：在采用模块化的工程里会有很多个模块和文件，需要构建功能把模块 分并个文彳牛o自动刷新：监听本地源代码的变化，自动重新构建、刷新浏览器。代码校验：在代码被提交到仓库前需要校验代码是否符合规范，以及单元测试是 否通过。其实以小见大，你能窥见的不仅是webpack的思想，更多的是前端的开展，从最初的土法炼钢，不规范，到如今的模块化、组件化、MV*框架，是前端思想的 进步。作为一个前端仔，我们应该探索和研究的是如何磨刀、磨好刀，而不是砍 柴而已。谢谢观看