前端 | 使用 require.js 和 webpack 简单对比

引子

项目前端脚本依赖使用了 require.js 做打包依赖，现在技术更新迭代之快，让人应接不暇，从 James Burke 在 2009 年 9 月 28 号 第一次提交开始，require.js 现在已经走过了将近 6 年的时间，当然，现在 require.js 还在不断的向前奔跑。

有朋友说 require.js 已经过时了，我保持沉默，判断一个事物的过时，个人觉得应该看看它有没有顺应技术潮流，我不知道 require.js 的未来是怎么样的，但是现在看到作者的不断更新，还是蛮开心的。

接着列一下都熟悉的新一代的工具：国内的 FIS, 国外的 webpack, systemjs 等等，这里面的工具都玩过，但还是着重聊下 webpack, 至于原因，是在项目的当前的结构下，require.js 和 webpack 可以无缝切换，webpack 第一次提交是在 2012 年 8 月，我是去年年初接触到的，批评下自己的嗅觉还是不够灵敏。

选择

之前写文章透露了前端架构选用了 require.js, 当时为什么没有选择 webpack, 原因：

• 相比较而言 require.js 更为熟悉
• 脚本加载缓存

这里详细说下第二个原因

使用 require.js

用 require.js, 我可以把全站所有的脚本打包成两到三个文件，全局加载，文件结构如下：

基本页面：全局加载

xxxxx


xxxxx

子页面：不同路由指向的页面

xxxx

xxxx

这里什么意思呢，也就是说全局加载了所有的模块，不同的页面直接调用相应的模块即可，显而易见的好处是不用打包时不用分发很多的脚本，但还是有些不爽的是：每个页面要单独写不同的加载逻辑

使用 webpack

不可否认，webpack 提出的概念值得学习和探讨，坊间不是有传言 Instagram 把 webpack 的作者 Tobias Koppers 捞了过去嘛。

用 webpack 打包，结构和 require.js 是不同的，我把公用的模块打包成一个文件，其他对应的功能模块自动分发

子页面 1

子页面 2

这里没有 require.js 的加载逻辑，因为子模块对应的文件加载后会自动运行。缺点：会产生多一些的脚本。

至于两者的比较，个人觉得应该结合场景，具体问题，具体分析。每个工具的侧重点不同。

这里择其中一功能点，乱谈一番