圈子首页 → ajax 开源 → JSI Side → 全部博客
2007-03-30

脚本安需导入(装载)的三种模式的对比

关键字: JSI JSIntegration

何谓安需装载？

脚本程序一般都是下载后执行 ，当脚本库非常庞大时，一次性下载起来非常费时，传统的解决方式是，按功能模块把脚本写在不同的文件中，页面上手动加入script标签装载指定内容，但 是这有一些缺点，类库的使用者需要知道没个脚本之间的关系，顺序要求等等，而不可能要求每个类库使用者都对其非常熟悉，出错的可能性很大。于是很多框架开 始支持导入指令，想使用什么一个导入函数就完了，不必一堆堆的script文件，不用小心翼翼的关注着他们的依赖关系。

安需装载可分如下三种模式：

  • 即时同步按需装载（阻塞，JSI、JSVM、dojo）。
    最简单的按需装载实现，通过XMLHttpRequest同步装载脚本文件实现。问题是，浏览器使用这种方式同步获取资源时将导致浏览器阻塞：停止响应用户事件、停止页面重画操作。所以，虽然编程最为简单，但是用户体验最差。
  • 异步按需装载（无阻塞，JSI2.0+）。
    异步导入，不必多做解释，用户体验好，但是因为其异步特征，处理起来比较麻烦。
  • 延迟同步按需装载（无阻塞，JSI2.0+）。
    JSI通过动态预装载功能实现的一种同步获取资源的方法，虽然也是同步，但没有阻塞，可以算时兼顾易用性和用户体验的机决方按。缺点时    有一定延迟，当前脚本标签中不可用。

使用方法（JSI示例）

以一个代码语法着色程序为例：
类库位置：example/codedecorator/code.js
页面位置：example/xxx.html
  • 即时同步按需装载
    js 代码
    1. $import("example.codedecorator.Code");
    3. var code1 = new Code();
    4. code1.id = "libCode";
    5. code1.decorate();

  • 异步按需装载
    js 代码
    1. $import("example.codedecorator.Code",function(Code){
    2. var code1 = new Code();
    3. code1.id = "libCode";
    4. code1.decorate();
    5. })

  • 延迟同步按需装载（无阻塞，JSI2.0+）。
    xml 代码
    1. <script>"../scripts/boot.js"><\/script>
    2. <script>
    3. $import("example.codedecorator.Code",true);
    4. <\/script>
    6. <script>
    7. var code1 = new Code();
    8. code1.id = "libCode";
    9. code1.decorate();
    10. <\/script>

示例说明：

下载后最好能放到一个能受到网速限制的服务器上，只有这样才能看到阻塞的问题。

第一次发布仅再ff上测试通过。

第二次发布修正ie上的错误。

第三次发布修正opera上的错误。

在线测试

http://jsintegration.sourceforge.net/example/code.html

http://www.xidea.org/project/jsi/example/code.html

参考：

JSI 导入函数： function $import(path, callbackOrLazyLoad, target )

JSI2 预览版下载：http://groups.google.com/group/jsier/files

评论
cozone_柯中 2007-04-04

jindw 写道：
nbimport.js的作用，我上个回帖已经说了。

JSI在这几种情况下有它的价值：
1。当脚本太多，依赖太多的时候，jsi可以将问题隔离，避免依赖扩散，命名冲突。
2。JSI的组件模型，页面装饰引擎，可以用在开发效率优先的项目中。保持页面简洁的同时，实现ria的功能。
3。JSI的组件模型是开放的，弱侵入的，任何类库开发者可以轻松开发自己的装饰库。

你说的依赖其他框架的太多的情况，jsi就有它的用武之地。
JSI是无侵入的框架，将第三方类库集成到jsi中是非常简单的事情，一般不需要修改源代码。只要描述好类库脚本元素（如函数，变量等）及其依赖。而且，集成之后，类库将比原来更加好用，至少你不必处处关心他们的依赖、类库之间的冲突、不用在页面上显式导入一堆你没有直接用到的脚本。


目前JSI才刚刚开始，只是一个预览版本。虽然现在影响不大，我对他的功能、技术、风格都是非常自信。
我现在正在参照xul编写一些常用的装饰器。下一此发布的时候，会许就能感受到它装饰引擎的优雅。


最后还有一个问题。比如gamail.这样完全不刷新的系统, 把所有js压缩到一起下载下来, 这称为模式1吧

模式2为jsi, 那种更好?

个人觉得模式1还是优于模式2, 因为js是有缓存的，想这样的系统加载一次js就完全不用考虑加载了


很期待你的jsi能越来越成熟，在下个项目里,我优先采用jsi, 因为我也感觉到该模式带来的方便,

 

jindw 2007-04-04
nbimport.js的作用，我上个回帖已经说了。

JSI在这几种情况下有它的价值：
1。当脚本太多，依赖太多的时候，jsi可以将问题隔离，避免依赖扩散，命名冲突。
2。JSI的组件模型，页面装饰引擎，可以用在开发效率优先的项目中。保持页面简洁的同时，实现ria的功能。
3。JSI的组件模型是开放的，弱侵入的，任何类库开发者可以轻松开发自己的装饰库。

你说的依赖其他框架的太多的情况，jsi就有它的用武之地。
JSI是无侵入的框架，将第三方类库集成到jsi中是非常简单的事情，一般不需要修改源代码。只要描述好类库脚本元素（如函数，变量等）及其依赖。而且，集成之后，类库将比原来更加好用，至少你不必处处关心他们的依赖、类库之间的冲突、不用在页面上显式导入一堆你没有直接用到的脚本。


目前JSI才刚刚开始，只是一个预览版本。虽然现在影响不大，我对他的功能、技术、风格都是非常自信。
我现在正在参照xul编写一些常用的装饰器。下一此发布的时候，会许就能感受到它装饰引擎的优雅。
cozone_柯中 2007-04-03
0.016 1110 GET 200 http://jsi.xidea.org/example/code-non-block.html
0.031 26489 GET 200 http://jsi.xidea.org/scripts/boot.js
0 214 GET 200 http://jsi.xidea.org/scripts/config.js
0 21 GET 200 http://jsi.xidea.org/scripts/nbimport.js
0.016 373 GET 200 http://jsi.xidea.org/scripts/preload/org/xidea/example/code/__$package.js
0.015 1265 GET 200 http://jsi.xidea.org/scripts/preload/org/xidea/example/code/code.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0 491 GET 200 http://jsi.xidea.org/scripts/preload/js/xml/__$package.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.015 3343 GET 200 http://jsi.xidea.org/scripts/preload/js/xml/template.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.016 4140 GET 200 http://jsi.xidea.org/scripts/preload/js/xml/tag.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0 1445 GET 200 http://jsi.xidea.org/scripts/preload/js/util/collections.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.016 212 GET 200 http://jsi.xidea.org/scripts/preload/js/io/__$package.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.015 2538 GET 200 http://jsi.xidea.org/scripts/preload/js/io/request.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0 680 GET 200 http://jsi.xidea.org/scripts/preload/js/io/writer.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0 471 GET 200 http://jsi.xidea.org/scripts/preload/org/xidea/syntax/__$package.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.016 4839 GET 200 http://jsi.xidea.org/scripts/preload/org/xidea/syntax/syntax-parser.js
0 0 GET (Cache) http://jsi.xidea.org/scripts/nbimport.js
0.016 2455 GET 200 http://jsi.xidea.org/scripts/org/xidea/example/code/code.css

这里已经很详细的记录了 在同步加载的时候重复加载 nbimport.js 文件。不知道是不是依赖关系造成的


其实从个人观点来说也是很喜欢按需加载模式的，而且jsi确实也表现的不错，
我也慢慢体会到jsi这种使javascript代码模块化的方便性，和轻松代码托管

不过我有几个疑问

1. 在目前的国内开发方式下，jsi的生存空间有多大？
2. 个人觉得很多项目依赖的js不多，要不就是依赖其他框架的太多，很难实现想jsi这样的管理模式
3. 还有就是在成型的项目中如何引入jsi进行有效的代码管理？
jindw 2007-04-03
测试的很详细嘛：）
1。jsi中每个脚本文件都不会装载第二遍。

2。延迟同步模式只能在页面装载过程中使用，其原理是一边打印缓存脚本（通过jsi编译后的预装载脚本），一边计算剩余依赖。每装载一个包之后，要计算剩余依赖。这里需要打印一个外部脚本，启动jsi的计算任务。这里多处来的请求都是这个外部脚本（nbimport.js）。

装饰器模式需要装载装饰引擎，需要遍历页面的装饰元素，固然比正常模式要慢一点，考虑装饰器带来的好处，这点开销一般还是值得的。

3。网络不好时打印源码，我没有碰到过。我想可能是页面没下载完吧。
cozone_柯中 2007-04-02
大概看了下jsi

想问几个问题

在按需加载的前提下

1. 如果有个功能基于一个触发条件,当我触发该功能的时候去异步模式状态,下次在调用该功能的时候,是不是意味着还要去请求该js文件?
如果我理解错了，不需要的话该如何实现？

2. 当网络非常阻塞的时候，即时同步模式（体验死机的感觉） 确实感觉不太舒服，相对延迟同步模式 就好的多。
以下数据是用 httpwatch 在网络状况比较好的情况下得出的结果，实际上 延迟同步模式 确实是在速度上要好，但是请求数明显增加。能否有更好的解决方法？


    类型 加载时间 加载大小
    即时同步模式（体验死机的感觉） 0.344 s 49063 k
    延迟同步模式 0.172 s 50086 k
    异步模式 0.358 s 51715 k
    装饰器引擎自动装饰模式 0.547 s 52992 k


3. 在网络状况不太好的情况下，似乎js经常会因为关联关系而在ff下十分不稳定，比如会直接在页面上打印出js源码，如果在这种情况下有没相关测试数据？
jindw 2007-03-31
radar 写道
如果你用的是document.write('<script>....</script>')
请注意。
http://ajax.org/space/JavaScript/script_tag_synchronous_or_asynchronous

小心陷阱！！！


你言中了，现在只是一个预览版本，上次传上去的例子只是ie，firefox上测试通过。
radar 2007-03-31
如果你用的是document.write('<script>....</script>')
请注意。
http://ajax.org/space/JavaScript/script_tag_synchronous_or_asynchronous

小心陷阱！！！
cozone_柯中 2007-03-30
jindw 写道
cozone_柯中 写道
其实

引用

异步按需装载（无阻塞，JSI2.0+）。
异步导入，不必多做解释，用户体验好，但是因为其异步特征，处理起来比较麻烦。
延迟同步按需装载（无阻塞，JSI2.0+）。


复杂就复杂在不稳定性，因为你要不停的判断是否下载完毕。其实也是一个等待过程


我已经吧代码示例贴出来了，是简是繁你一看便知。
是的，异步的处理是比较麻烦，但是没你想想的那样，如果框架支持的好，化繁为简完全可能。
异步导入，简单的话，用回调函数就可以，复杂一点的，jsi基础类库中有任务队列支持。

jsi2的装饰框架，全是异步安需装载的。有一个队列，收集信息，装载资源，执行装饰行为（深度优先），如果有兴趣你可以翻翻代码。


嗯。一定拜读一下代码
jindw 2007-03-30
Readonly 写道
像bindows,qooxdoo用一个splash window先显示loading %，一次读入所有的js，可以被分到哪一种？


你自己都说了，一次装载全部，那就不是安需装载了：）

这几个框架没有研究过，不清楚，居然可以显示loading ％，那么异步装载的可能性大点吧。
jindw 2007-03-30
cozone_柯中 写道
其实

引用

异步按需装载（无阻塞，JSI2.0+）。
异步导入，不必多做解释，用户体验好，但是因为其异步特征，处理起来比较麻烦。
延迟同步按需装载（无阻塞，JSI2.0+）。


复杂就复杂在不稳定性，因为你要不停的判断是否下载完毕。其实也是一个等待过程


我已经吧代码示例贴出来了，是简是繁你一看便知。
是的，异步的处理是比较麻烦，但是没你想想的那样，如果框架支持的好，化繁为简完全可能。
异步导入，简单的话，用回调函数就可以，复杂一点的，jsi基础类库中有任务队列支持。

jsi2的装饰框架，全是异步安需装载的。有一个队列，收集信息，装载资源，执行装饰行为（深度优先），如果有兴趣你可以翻翻代码。
Readonly 2007-03-30
像bindows,qooxdoo用一个splash window先显示loading %，一次读入所有的js，可以被分到哪一种？
cozone_柯中 2007-03-30
其实

引用

异步按需装载（无阻塞，JSI2.0+）。
异步导入，不必多做解释，用户体验好，但是因为其异步特征，处理起来比较麻烦。
延迟同步按需装载（无阻塞，JSI2.0+）。


复杂就复杂在不稳定性，因为你要不停的判断是否下载完毕。其实也是一个等待过程
cozone_柯中 2007-03-30
jindw 写道
cozone_柯中 写道
个人感觉在js不是很大的情况下 同步加载系统才是最稳定的


我只能说同步装载是最简单的，但是，阻塞问题会让你无法忍受。



我的同步加载的意思是 ， 当js代码不是很多（使用了压缩），页面还没有展现的时候一起打包下载下来，
这样就不存在后续的问题了。

其实当压缩后第一次访问js代码在500k左右是可以接受的
jindw 2007-03-30
cozone_柯中 写道
而且加载也就一次吧, 下次进来就有缓存了


问题是网速慢，阻塞严重时，用户进去一次就没有第二次了。

以前jsi1.1集成的那些例子，dojo的例子。都可以去忍受一下，死机的感觉。

jsvm聪明一点，所有的例子都是打包的，没有用到真正的安需装载。
还有他是国内的站点，快就一个字
jindw 2007-03-30
cozone_柯中 写道
个人感觉在js不是很大的情况下 同步加载系统才是最稳定的


我只能说同步装载是最简单的，但是，阻塞问题会让你无法忍受。
cozone_柯中 2007-03-30
而且加载也就一次吧, 下次进来就有缓存了
cozone_柯中 2007-03-30
个人感觉在js不是很大的情况下 同步加载系统才是最稳定的