requireJS r.js 的弊端？

Question

如果正常用 requireJS 的话，都是异步加载的，没什么问题。
我的问题是：当在node环境中，用 r.js 合并压缩所有依赖的文件的话，那也就是说，在客户端浏览器上会一下子加载整个网站所有的脚本（以及需要加载的所有text片段，如果有的话），也许看上去节省带宽（总体上）节省连接次数，但是这样会使得浏览器内存中会一下子创建整个网站的各种对象（本不应该在当前页面加载的）：
比如问题比较严重的backbone中所有的Model、Collection、View，以及Router。我觉得这貌似是个很严重的问题，求大神解答 :-)

Answer 1

我曾提出了类似的问题，其中提到，分业务合并压缩脚本的问题。里面有部分答案还是值得思考的，分享与你

基于requirejs的前端模块化工程，可以选择什么工具来实现自动化压缩和合并

Answer 2

关于这个问题，我之前也有过相似的疑问。后来查阅了一些资料，以及请教了一些前辈之后，大概有了些自己想法。

首先requirejs实现的是amd规范，当你在使用requirejs进行开发的开发的时候，因为要模块化，所以会产生很多js文件，特别是跟backbonejs一起用的时候。

在网络资源请求的过程中，加载一个体积稍大一点的文件远比加载许多个体积小的文件要节省资源的多。

所以基于这个因素，使用requirejs将整站的脚本文件打成一个文件也无可厚非。

至于你的问题，如果将所有的脚本文件直接打成一个main.js，那就意味着可能并不是我当前页面需要的脚本文件也会在当前页面加载了。我个人觉得这可能就是一个文件数量和文件体积的把握了。要看项目的具体要求。

此外，如果在SPA（或者非SPA）中，我们可以按照功能模板将页面人为分类，然后每一大类下所有页面的脚本文件打成一个文件，这样根据不同功能页面的入口加载不同的打包好的文件，应该能够稍微避免之前的那个问题了吧。

Answer 3

多页面的时候用不了缓存