JSI2.1计划

先回顾历史：
JSI1（2006-2007）是个简单的框架，只有脚本级别的依赖管理，只有阻塞同步装载模式。

JSI2 （2007-2008）是个庞然大物，同步装载，异步装载，延迟装载，装饰引擎。。。。。
网撒的太宽，而且学习曲线也非常陡峭。

JSI2.1 新的2008，JSI2也打算做点改进。
时至今日， JSI已经有两年多的历史了，自己也在大大小小的项目中有了不少实践，普遍的反映是。内核庞大。依赖管理复杂，难以掌握。

确实，JSI的依赖管理非常复杂，而且内核源码的组织也不够完美。装饰引擎，异步装载，等等，全部混合在一起，别说他人，我自己看着也头晕。当时的借口：压缩优化。得了，为了压缩损失代码的可读性，实在是有点笨。改吧：
初步决定的重构点如下。

1。新的定位
以前都吧JSI定位成运行时的脚本管理，经过一年多的实践，发现，让他作为开发期的脚本管理更有价值。因其无侵入的特征，开发结束后，导出脚本就是。光脚的不怕穿鞋的，没有装载器的束缚，跑的更快。

2。去除js.*.*包，内核不包括任何托管脚本。
JSI2中有些包是内核用到的，比如异步装载就需要队列管理（js.util.TaskQueue）。
还有，总想写一些大家能公用的基础包，实事证明，没那个必要，保留框架的简单最重要，这次重构的目标之一就是吧引导文件控制在10k以内（补充一下第一 条，我虽然吧JSI做成开发期的脚本管理框架，运行时同样支持，10k的附加引导文件，轻微的装载开销，我想还是能被大多数用户接受的）。

3。把装饰引擎和异步装载延迟装载从内核中剥离。
JSI的一个重要目标是无侵入，当时这个已经给依赖管理变得复杂了，而我们还吧这一堆东西困在一起，导致一个core.js就达到了2000行的代码，实在有点过。重新规划。

boot-core.js	简单内核
boot-lazy.js	扩展简单内核中的import函数，令其支持异步和延迟两种装载模式
boot-decorator.js	装饰引擎支持。

后两个脚本是可选的，如opoa中，我们理当吧全部脚本打包在一起，这时，就完全没有异步装载和延迟装载的必要。而装饰引擎更是没必要强行推销。

4。删除CSS导入功能，删除内置日志功能。
JSI的内核已经够庞大了，这些不常用的功能就不要给我添乱了^_^

5。重构脚本定义函数
原来用于脚本管理的函数有:

this.addScript(file,objects)
this.addObjectDependence(object,
dependenceObject,
isBeforeLoadDependence);
this.addScriptDependence(script, dependenceScript, isBeforeLoadDependence);
this.addObjectScriptDependence(object, dependenceScript, isBeforeLoadDependence);
this.addScriptObjectDependence(script, dependenceObject, isBeforeLoadDependence);

 

好复杂啊，重构成:

this.addScript(file,objects,beforeLoadDependences,afterLoadDependences)
this.addDependence(object,
dependenceObject,
isBeforeLoadDependence);

 

重构理由：
把添加脚本和添加依赖放在一起，更加简单方便了。不过，这样我们只能添加整个脚本的依赖，如果要添加单个对象的装载后依赖（很少见），还是的借助addDependence函数。
四个添加脚本依赖函数，没必要吧？到底是脚本依赖还是对象依赖完全可以自动探测，何必给用户添加麻烦。

6。脚本定义时*模式的支持（调试模式）。
很多人都认为JSI的包定义语法有些复杂，比如我们定义一个脚本，还需要指出我脚本里面的元素名称，那些东西我都在源文件里var function什么的都申明了啊！！
确实，如果你只是想吧你在源文件中申明的东西全部暴露出来，我们一直都没有一个简单有效的办法，现在，我们将引入*模式。
包定义实例：

 

this.addScript('youscript.js','*')

关于实现，这确实是个大问题，我们需要用脚本分析你的js文件，找出你定义的全部变量、函数。是个较大的开销。所以，我们只能在调试模式下支持该功能，产品发布时，可以在脚本编译时计算出准确的变量名称数据。

7。异步装载和延迟装载的优化。
首先，我决定取消包的非即时装载功能，理由，包定义文件本来就很小，没必要。而且一旦放开了这一枷锁，实现将简单很多很多。

8。调试支持附加功能
调试支持涉及到很多的内容。
1。IE7原生XHR不支持本地文件访问。这样一来无法本地调试，所以，我们还要为IE7做特殊处理。
2。延迟装载的调试时最友好的，应为它不是用eval装载的脚本，可以很方便的找到出错位置。但是，这需要编译支持的，我们不能修改后马上见效。这样，我们就可以借助非ie浏览器支持的data协议，脚本内编译预装载脚本。
。。。。
这些东西，开发期的东西，写的大一点，多一点，升值性能低一点，无所谓。上线时踢出了照常运行^_^




此外，我还打算支持一些其他装载模式。
比如，我们可以吧JSI以最简单的方式工作，如，不需要装载单元的隔离。
不需要依赖管理
这样虽然有点退化的感觉，不过也是一种普及JSI的办法，JSI的思想有点超前了，曲高和寡，不如做点简单的东西，让大众也能接受东西。