5

引子

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

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

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

选择

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

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

这里详细说下第二个原因

使用 require.js

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

基本页面:全局加载

xxxxx
<script src="require.min.version.js"></script>
<script src="desk.min.version.js"></script>
xxxxx

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

xxxx
<script>
    require('moduleA', function(moduleA) {
        new moduleA();
    });
</script>
xxxx

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

使用 webpack

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

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

子页面 1

<script src="global.min.version.js"></script>
<script src="app1.min.version.js"></script>

子页面 2

<script src="global.min.version.js"></script>
<script src="app2.min.version.js"></script>

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

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

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


青阳半雪
1.6k 声望24 粉丝

现实与完美之间