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

嗯。一定拜读一下代码

如果你用的是document.write('<script>....</script>')
请注意。
http://ajax.org/space/JavaScript/script_tag_synchronous_or_asynchronous

小心陷阱！！！

你言中了，现在只是一个预览版本，上次传上去的例子只是ie，firefox上测试通过。

大概看了下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源码，如果在这种情况下有没相关测试数据？

测试的很详细嘛：）
1。jsi中每个脚本文件都不会装载第二遍。

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

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

3。网络不好时打印源码，我没有碰到过。我想可能是页面没下载完吧。

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进行有效的代码管理？

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

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

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


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

jindw 写道：

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

模式2为jsi, 那种更好?

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

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