116  
查询码:00000756
前端构建工具发展史
作者: 朱凡 于 2022年02月18日 发布在分类 / FM组 / FM_App 下,并于 2022年02月18日 编辑

近10年是web前端极速发展的10年,前端这10年的发展在其他编程⽅向⽐如Java后端看来,简直就像蜗⽜看⻅兔⼦⼀般。在这个过程中,前端构建⼯具的发展则尤为令⼈瞩⽬,这跟前端应⽤的复杂度⼤⼤提升,以及JavaScript标准快速推进落地有很⼤的关系。

前者让前端开发不能再局限于⼀个⻚⾯⼏个js⽂件就可以搞定的开发⽅式,古早的前端开发其实是作为后端的附属,数据交互是由后端的模板引擎渲染的,所以前端只需要做⼀些交互动画之类的,所以可能⼀个⻚⾯只需要⼀两个js⽂件就够了,那时bootstrap和jquery之类的⼯具是最为流⾏的,因为可以⽅便的获取节点并进⾏⼀些dom操作。但是随着应⽤复杂度的提升,⼤量的数据交互放到了前端,同时为了体验⻚⾯跳转的⽅式也希望不要等待刷新的过程,这让前端不再是⻚⾯,⽽更像⼀个应⽤Application,那就不能按照⻚⾯的开发⽅式来做了。

⼆后者是前端届⼀直在努⼒推进的标准,遥想曾经,ie6-8是所有前端的噩梦,不同浏览器的兼容甚⾄是前端招聘的硬性指标,各种千奇百怪的兼容⽅式层出不穷。⽽ES标准的推进,让前端开发者也看到了摆脱兼容性束缚的希望。在这个过程中,把ES标准的语法编译到⼤部分浏览器兼容的语法的需求越来越强⼤,也就催⽣出了编译⼯具,⽐如babel。同时ES标准也补上了了模块加载的标准,让JS不再只是脚本,也是⼀个完整的编程语⾔,在JavaScript标准和浏览器执⾏两者的拉扯下,构建⼯具⾃然是必不可少的了。

过程

古早时代

然⽽构建⼯具的发展也不是⼀蹴⽽就的。最开始的前端开发是没有模块的概念的,那时对于JS的要求是我们写了⼏个脚本,我们希望这些脚本能够集成到HTML,并且能够满⾜⽂件尽量⼩,HTTP并发数量可控,以及可以做到缓存。所以那时候整体上的⼯具就是围绕单个⽂件的操作。


曾经⻛靡⼀时的雅⻁前端优化10条就包含了上⾯的这些点,⼆YUItools就是那时候的佼佼者,他能够帮助我们压缩js⽂件并且适当地完成混淆。但很多时候也就仅限于此,那时候前端并没有多少话语权,同时前端的编程能⼒也较为羸弱,那时候有些前端甚⾄被称为美⼯,或者⻚⾯仔。对于像HTTP请求的优化,更多其实是由后端服务开发⼯程师来做的,前端没有权限或者也没有能⼒来做到。

grunt&gulp

虽然把他们放在⼀起,但是grunt其实⽐gulp要早很多,我们可以理解为gulp是grunt的升级版,但总体上他们⼲的事是⼀样的。相⽐于现在的Webpack之类的构建⼯具,他更多是⼀个任务管理⼯具,通过⼀些列细节的⼩任务,进⾏不同的组合来达成⼀个完整的任务。但是具体任务做什么其实是使⽤者⾃⼰决定的,虽然grunt也提供了⼀系列⼯具来进⾏集成,但是其本身并没有规定任何的模块管理还代码打包的事宜,所以总体上来说构建功能仍然是缺失的。

gulp相⽐于grunt并没有本质的提升,只是在任务管理⽅⾯有了⼀定的提升,包括任务执⾏⽅式,⽂件流转⽅式,以及相对应的性能等。所以这边就不再赘述。

browserify


browserify可以称得上是第⼀代前端构建⼯具了,他是⾸个采⽤了nodejs的模块管理⽅式–

即require,module.exports的模块加载和导出⽅式–来进⾏前端项⽬打包的⼯具。当你在js代码中使

⽤require('./xx.js')这样的代码,browserify会帮助你去加载对应的⽂件并且可以把对应的⽂件进⾏link和合并,最终产出前端需要的合并⽂件。

但是相较于webpack,browserify仍然只能打包js,对于css、图⽚等,你仍然需要依赖当时还很流⾏的grunt、gulp这样的⼯具进⾏处理,你需要为这些⽂件单独写处理任务,再结合browserify来最终完善整个应⽤。这⼀⽅⾯在使⽤体验上⽆法进⾏统⼀,另外其兼容⽅式并不是那么地完善导致体验并不理想。

也因为此,browserify最终败给了webpack。

webpak&rollup

webpack和rollup本质其实也是js构建⼯具,但和browserify相⽐,他们在使⽤⽅式做了更全⾯的设计,其本身就已经是⼀个核⼼,并且具有了⼀定的任务管理的能⼒。他们都具有插件集成的能⼒,并且webpack还具有loader的机制来帮助我们应对不同类型⽂件的引⼊需求。在这样强⼤能⼒的基础上,越来越多原先集中于gulp等任务管理⼯具的能⼒都被迁移到了webpack和rollup阵营。现在我们只需要⼀个命令就可以完成⼀个⼤型应⽤对于各类不同资源的引⼊需求,webpack能够帮助我们管理代码打包,资源加载,代码压缩等等web前端的⼤部分需求。

似乎到这⾥,这个⼯具已经很完美,我们所有的需求都已经得到了满⾜,我们对于前端构建还有什么不满意的地⽅吗?有!主要集中在两个点:

1.配置过于繁琐

2.慢!

如果我们单纯使⽤webpack来管理项⽬,那么很可能你的项⽬⾥会出现数个不同的webpack配置,他们要么⽤于不同的环境,要么就是⼀个⽂件太多要进⾏拆分,webpack的配置内容实在关于多,以⾄于新⼿⼀开始完全摸不着头脑。这主要是因为webpack为了满⾜更多的场景,会不停的增加功能,同时因为webpack是太多的插件了,这些插件也需要学习,就导致其学习成本⾮常巨⼤。

⽽第⼆点则是有⽬共睹的,⼀旦我们的项⽬达到⼀定的规模,webpack的启动速度就难以令⼈满意。上1-2两分钟时⾮常正常的,⼤⼀点的项⽬⽐如后台管理,10分钟也是⼈之常情。另外⼀点就是热更新的速度,这⼀点上也不令⼈满意。

那么这些问题真的能解决吗?能,Vite就是为此⽽⽣的。

Vite,未来


到这⾥我已经不太想讲Vite有哪些功能⾥,因为上⾯说的功能他基本都有。得益于Vite采⽤rollup作为底层,并且⼤量兼容了rollup的API,其发布初始就具备了⼤部分的rollup⽣态能⼒,所以也不存在Vite功能缺失很多的问题。我们来细数⼀下Vite是如何解决上述的webpack存在的问题的:

VIte的配置并不繁琐,因为其预设就是为前端项⽬开发⽽⽣,所以对于dev-server,css依赖,图⽚加载之类的功能其都配置成开箱即⽤,你完全不需要再去配置插件、loader之类的。所以很可能你的vite配置不会超过20⾏代码,这在webpack项⽬中基本不太可能。

⽽第⼆点,Vite在开发环境中采⽤ESM的模块加载⽅式,并且尽可能剔除了不必要的代码构建,同时采⽤了激进的Esbuild–⼀个⽤go语⾔开发的JS编译⼯具,性能是webpack之类的10-100倍–来进⾏编译提速,这就让Vite启动速度极其迅速,基本3秒内就能就能完成。同时得益于ESM加载⽅式,Vite不需要提前进⾏代码打包,所以即便你的项⽬变得巨⼤,但是Vite并不关⼼你的⽂件规模,所以他的启动速度仍然不会有太多的变化。对于开发时的编译也类似,我们就不在赘述。

总结

那么是否Vite就是最终的前端构建⼯具了呢?并不⼀定⻅的,发展的道路是⽆⽌境的,现在我们流⾏使⽤前端框架进⾏开发不代表未来就仍然是这样的开发模式,可以说这⼀波构建⼯具的快速发展和前端框架的⽇趋完善是脱不了⼲系的,⽽⼀旦下⼀个世代的开发模式到来,那么前端的构建⽅式仍然有可能产⽣⼤的变化。



 推荐知识

 历史版本

修改日期 修改人 备注
2022-02-18 23:43:57[当前版本] 朱凡 创建版本

 附件

附件类型

JPEGJPEG

知识分享平台 -V 4.8.7 -wcp