前些日子来到广州,然后见了见菜哥。

菜哥是之前深圳工作的同事,写py后端,算是前辈。
尽管已经离职三个月了。和菜哥还是会有交流。

前些日子菜哥想试试重构我当年留下的一些旧代码,提出了想试试gulp+webpack。

然后我提出了自己的观点。不要在该项目使用webpack。


当初只是从感性上觉得webpack的设计理念不适合该业务,但是并没有深入思考过是那些点不合适。

故做一下整理。

菜哥想重构的是一个多页面项目。当时我没有这方面的经验,外加最初的技术尝试选型错误,故架构很烂。重构是个正确的选择。

先分别说说两个工具,二者都是属于前端自动化的工具类应用。但是在设计理念上有着根本的区别。

  • gulp
    gulp可以算作是grunt的优化版,主要是以管道流的思路为核心。通过搭建各种管道流来对相应的文件做所需的压缩、替换、打包、复制等功能。

  • webpack
    webpack的思路在现今的自动化工具中比较新颖,主要以模块化为核心思路。所有资源均可以打包,js直接引用css、img等资源,形成一个模块。

二者虽然都是自动化工具,但是可以看出二者的设计理念完全不同。所以gulp+webpack其本身的思路,并不能说是有问题的。

那么问题出在哪里?

便是实际的业务需求上了。

从我个人的工作经历上来看。前端的工作需求主要分为两种。

一种是单页应用(SPA),一种是页面站点。

而之前聊到的业务,就属于页面站点而已。

该页面单页所需功能不多,且视图层级并不复杂。

在其本身逻辑并不算复杂的情况下强行使用模块化的方法反而是无谓的提高其开发和维护的成本。

即一个页面,本身可能js代码几百行,css几百行。

却被强行拆分成几个小模块,每个模块几十行js和css,甚至几行都有可能。

一个页面会被拆分成几个模块,那么好几个页面呢?

不同的页面其ui和功能又会不同,每个功能都不复杂。

只是单纯的为了少量的重用,而导致其复杂程度以指数的增长。

这就是典型的过渡优化。

那么不做模块呢?依旧按照css html js分离。

则webpack的存在毫无意义。