Ext 2.0 for JSVM

确实如此。所以我倾向于我们可以达成这样的共识：

在代码中的$import指令应该总是同步加载。
而在外部描述（或者类似jspkg那样有少许侵入性，但是也是在代码主体之外声明依赖性的框架）中声明的依赖性，则可以通过配置决定采取哪一种装载方式。

绝对可以。jsi和pies都有实际运用的例子。例如我们都给每个单元注入了log。

对于js来说无所谓是否是Factory。而对于jsi,pies这样的无侵入式，或者干脆点说，就是注入式框架来说，更无所谓是否用Factory，而是跟spring类似，可以在配置文件里配置某个namespace实际上由哪一个单元提供实现。这也允许在一个应用里使用同一个类库的多个版本等非常复杂的需求。

这种方式存在一些弊端。因为它把逻辑单元和装载单元强行一一对应起来了。所以我决定在pies中舍弃这种方式。

注意，java和C#都并非是这样的。C#大家好理解。java其实也不是这样的。虽然默认是一个类一个文件，但是这只是一个缺省约定，从本质上说，classloader是可以采取其他的策略的。而且java在源码中不会出现文件系统。（这与ruby形成了对比。）所以不存在文件系统和逻辑组织的耦合。

我们之所以讨厌dojo，一个原因就是它的包系统是把逻辑单元和文件系统耦合在一起的。ruby也有同样的问题，但是他们似乎并不是很care这个问题。我不是ruby中人，暂时无法予以理解和评论。

这一点无法苟同。在Java中，类是最小单位。但是真正的代码组织其实并非以类为单位。因为常常会有一组关系紧密相互协作的类。我们通常称之为模块。它内部高内聚，对外则低耦合。Java中一般会以package为这样的单位。所以，在其他语言里，如果把所有的核心类写到一个源文件里或者把许多个class文件存放在一个module文件里，也并非不可以。即使在Java中也有类似的情况，在模块规模不大的情况下，可以用一个大类嵌套几个类。当然可以看到还是产生了几个类文件。但这至少说明很难说是“必须严格遵循”。特别是脚本语言的表达力强，有时候一个类也许只有10行代码。把若干个相关文件合并到一个源文件里并非不可以。关键是要掌握好度。我认为合适的度是，一个源文件里最多只能有一个加载单元或者说是模块依赖的单位。当然可以把一个加载单元分散到几个源文件中。但是反过来不行，部署时候的合并是另外一个事情，与源代码无关。

这样一种设计偶是不能接受的。

Java2Script的做法是，打包时，把一些*.js文件，连接成为一个或者多个大的*.z.js文件，这个过程就类似Java打包*.class为*.jar文件一样。

Java的ClassLoader有一个搜索*.jar文件来加载对应*.class的策略。而Java2Script的ClassLoader要加载一个*.js，则根据配置（一个package.js文件），对应改成加载*.z.js，而同时该*.z.js中的其他类也会被同时加载。

源代码的管理方式和*.js的打包加载方式不用一一对应。

首先，异步加载和异步调用不是一回事。

其次，我自己也承认如果没有Java2Script提供Java匿名类的写法，手动写异步调用的javascript代码确实很痛苦，传递参数等等很繁琐。

但是有一点，异步调用并不是想象中的不可接受。当然，有工具支持最好；没有工具的话，确定一个模式，熟悉后就很好用了。

我个人觉得，以后异步调用会越来越多人用。

严格按照一个“类/对象”对应一个相同名称的文件的方式保存，也是指设计时“源代码”的文件组织方式，与工作时的装载属于不同的两个层面，不会造成之间的强耦合。（我对dojo的了解不够深入，通过一个插件对dojo的装载方法作切面，是否可使其与文件系统解耦呢？一个猜测:) ）
其实它还隐含了一个前提条件，就是：类似 public class 的才会被要求以单独文件保存，类似 inner class 的设计，可不必另存单独文件的。
现在看，实现js自动化加载管理有两种方式：

1. 约定一个“类/对象/模块”与代码文件路径的对应规则。
2. 在外部通过其它方式来描述这种对应关系。

我的观点是：基于高内聚低耦合的原则，逻辑单元对其它单元的引用和依赖不属于接口/协议的范畴，属于内部实现，应是不被外部了解和维护的。所以我倾向第 1 种方式。但为了实现将现有的lib按需加载而同时不侵入，2 也是一种好的方案，也可能是唯一的方案。