最近有点忙,很久无写博客,记录一下之前的配置require.js和sea.js的配置.(有误有望提出require.js文件目录 /app(项目使用js)/lib(require.js jq存放处)/plugin(框架对应的功能插件)require.js比较方便在于,不是a ...
最近有点忙,很久无写博客,记录一下之前的配置require.js和sea.js的配置.(有误有望提出
require.js
文件目录
/app(项目使用js)
/lib(require.js jq存放处)
/plugin(框架对应的功能插件)
require.js比较方便在于,不是amd的模块组件可以通过配置文件进行依赖配置.而且异步加载js 页面加载速度是杠杠的.当然会有点问题的,网速过慢的话,可能会出现js,timeout(可以通过配置解决.
config.js (配置文件)
// 配置信息requirejs.config({ // 模块的基准路径 baseUrl: 'js/lib', // 映射不直接放在baseUrl下的模块名 paths: { app: '../app', plugin: '../plugin', jquery: 'jquery-1.9.1.min', lazyload: '../plugin/jquery.lazyload.min', base: '../', controller: '../app/controller', model: '../app/model' }, // 为没有使用define()的模块声明依赖关系 shim: { lazyload:{ deps: ['jquery'], exports: 'lazyload' }, 'plugin/placeholder':{ deps: ['jquery'], exports: 'placeholder' } }, // 设置请求超时时长，设为0时表示不限超时时间 waitSeconds: 0});在开始之前我已经假设你对requirejs与seajs语法已经基本熟悉了，如果还没有，请移步这里：- CMD标准：
https://github.com/cmdjs/specification/blob/master/draft/module.md
## 加载差异这一小节请允许我照搬一个帖子玉伯转过的一个SeaJS与RequireJS最大的区别，这个帖子原始(不包括后记)的结论是
RequireJS你坑的我一滚啊, 这也就是为什么我不喜欢RequireJS的原因, 坑隐藏得太深了.
define(function(require, exports, module) { console.log('require module: main'); var mod1 = require('./mod1'); mod1.hello(); var mod2 = require('./mod2'); mod2.hello(); return { hello: function() { console.log('hello main'); } };});
require module: mainrequire module: mod1hello mod1require module: mod2hello mod2helo main
require module: mod2require module: mod1require module: mainhello mod1hello mod2helo main
但问题是，为什么"执行模块的顺序"应该是"严格按照模块在代码中出现(require)的顺序"? 并且"这样才更符合逻辑吧"?如果他以seajs的运行结果来要求requirejs，那requirejs肯定吃亏了。AMD标准从来都没有规定模块的加载顺序，它只是需要保证：
The dependencies must be resolved prior to the execution of the module factory function, and the resolved values should be passed as arguments to the factory function with argument positions corresponding to indexes in the dependencies array.
我个人感觉requirejs更科学，所有依赖的模块要先执行好。如果A模块依赖B。当执行A中的某个操doSomething()后，再去依赖执行B模块require('B');如果B模块出错了，doSomething的操作如何回滚？ 不但考虑这样一种业务情况，考虑某一个功能只对登陆用户开放，这样的话requirejs提前把模块加载是否有必要？(因为来到你页面的用户到离开也不会登陆)。这是非常实际的问题，一个页面可以有非常多的功能，比如登陆、分享、留言、收藏……但不一定每一个来到页面的用户都会使用这些功能，如果都作为页面模块的依赖提前加载的话，对页面一定是一个不小的负担。但seajs可以即用即加载，比如代码可以这么写define(function () { if (user_login) { require(login_feature_module) } document.body.onclick = function () { require(show_module) }})
很多语言中的import, include, useing都是先将导入的类或者模块执行好。如果被导入的模块都有问题，有错误，执行当前模块有何意义？
你会不会觉得我上面说的懒加载是一种天方夜谭？但然不是，你去看看现在的人人网个人主页看看![记录:sea.js和require.js配置 与 性能对比]()
图中标注的“与我相关”、“相册”、“分享”都是在点击之后才加载对应的模块Facebook的情况更为严重，不仅要考虑内部不同团队的功能模块，还要考虑第三方的功能模块。早在09年，他们就是用了一套静态资源管理方案(Static Resource Management)，用于管理一个功能所需要的js/css静态文件：
简单来说，就是由页面上有没有功能所需的html片段，来决定是否加载和打包功能所需的js与style。也就是说静态文件需要通过html“声明”之后才可用。具体可以参考这里：Frontend Performance Engineering in Facebook : Velocity 2009为了增强对比，我们在定义依赖模块的时候，故意让它的factory函数要执行相当长的时间，比如1秒：seajs加载的瀑布图：如果把一个模块的执行拆分为执行define和执行factory函数的话(对requirejs和seajs都适用)，从上图可以看出：- requirejs：一个模块的factory函数执行是紧跟随在define(也就是Evaluate Script脚本模块文件)之后
- seajs: 执行一个模块的factory函数需要等待所有模块define完毕。
在上面一节中我提到了懒加载模块，在加载模块的时候需要1. 临时请求模块文件 ; 2. 执行factory函数。但如果我们在载入页面时仅仅是执行把懒加载的模块的define(从上面两个图可以看出define的代价是非常小的)，而设法不执行factory函数。那么在真正需要懒加载的时候只要执行factory函数即可。这样不是能够让模块响应更及时，更靠谱？这是可以实现的。但技术细节就不赘述了。这可以作为优化模块加载的一种方案。
那么也看看上述引用文章的后记吧
注意我这里说的是执行(真正运行define中的代码)模块, 而非加载(load文件)模块.为了说明阻塞的问题, 翠花上图
![记录:sea.js和require.js配置 与 性能对比]() |
| SeaJS的懒执行注意图中巨大的pinyin-dict.js模块, 取自pinyin.js, 复制了N次后以增加它的"重量", 增强演示效果, 大家有兴趣的话可以亲手试试.可以很明显的看出RequireJS的做法是并行加载所有依赖的模块, 并完成解析后, 再开始执行其他代码, 因此执行结果只会"停顿"1次, 完成整个过程是会比SeaJS要快.而SeaJS一样是并行加载所有依赖的模块, 但不会立即执行模块, 等到真正需要(require)的时候才开始解析, 这里耗费了时间, 因为这个特例中的模块巨大, 因此造成"停顿"2次的现象, 这就是我所说的SeaJS中的"懒执行".最后感谢大家的各种意见建议, 我这里并没有说SeaJS与RequireJS哪个更好一些, 仅仅是为了说明下他们的区别, 各种取舍请大家根据实际情况来定, 希望能帮到大家. 看到这里,估计都明白了,针对情景不一样,最后在于大家的取舍了.
海外公司注册、海外银行开户、跨境平台代入驻、VAT、EPR等知识和在线办理：https://www.xlkjsw.com
原标题：记录:sea.js和require.js配置 与 性能对比
关键词：JS
*特别声明：以上内容来自于网络收集，著作权属原作者所有，如有侵权，请联系我们：
admin#shaoqun.com
（#换成@）。
|
