关于 jsvm 的争论

jsvm api 很简单,学习成本很低,原则上会使用 _$import(类名) 或者 Class.forName() 就行了，那些额外的语法可以不用去理会！


第二步，第三步的开发不是jsvm的事，和jsvm没有关系。jsvm 关注的是代码组织结构，他能做到足够简单和灵活就可以了！丰富的API可以在jsvm之上开发的。目前你还看不到我说的 第二步和第三步，因为还没有发布这一块的产品！


其实目前属于百家争鸣的局面，选用某种技术有时候取决于开发团队的技术背景和一些客观环境应用场景等因素。
但在原则上，我不赞成js要借助另外一门语言来变相地实现它本身也能实现的功能！


js.util.ArrayList/HashMap 等类在某种意义上是为了在开发中简化你的代码而设计的，当系统整体复杂到一定程度，个体在形式上的简单才显得重要起来，所以对这些类的复用频度取决于你的代码是否足够复杂！简单的应用我觉得直接用object和hash功能和array就可以了

这一段能不能再解释一下，不是很理解。

就是那一套配置和加载*.js的机制？是否说详细一点，是怎么样的代码组织结构，如何让开发者感觉到简单和灵活？


实际上编程语言越来越相似，Java、C#就已经相似了，如果能够简单地直接借用一种其他语言已经实现的功能来完成一项功能，又何必再去制造a rounder wheel呢？

JSVM也是参考Java的一些成功结构或者经验吧。所谓“变相”，究竟是一项技术还是一项技巧呢？SOA要干的是什么？整合不同的系统下、不同架构下、不同语言实现的已有应用！为什么是要整合？而不是制造一个新的轮子？如果用Java2Script可以在JavaScript中实现Java中已经实现的功能，又何乐而不为呢？

这里我描述的确实不太清楚，我的意思是：
JS UI Component 最终还是通过 HTML 来描述界面，当 js object 的数据发生变化或者执行某个动作时，需要通知到对应的html，使其发生相应变化。于是js object 需要得到他在页面上对应的html的句柄，通常做法，是在创建html的时候将createElement返回的句柄保存在js object 内部的某个变量中，或者赋值给html eLement一个唯一的ID，js object 根据这个ID来找到对应的HTML Element。同样，当htm elementl的事件（例如onclick）要通知到相对应的 js object 或者回调js object的某个方法或属性时，也需要得到该js object的一个引用。我的意思是建立一种统一的规则，js object 和他相对应的 html 能通过这种规则互相访问到对方。 建立这个关联以后，实现js object和对应 html 的数据邦定和数据同步等问题就简单多了

将js代码按照对象的划分方式切割存放到相对应的jsc文件中，于是代码的复用粒度和开发粒度，维护管理粒度、加载粒度统统都保持一致了。另外，可以根据js class 的类名找到对应的代码，于是就可以实现自动维护代码之间的依赖关系了。这和java的class文件存放规则是类似的。

整合不是目的，而是不得已，因为现有的系统，架构，平台尚不统一。SOA屏蔽了这些差异，统一了系统对外接口的形式。但是，如果我们在起始阶段就能尽量采用统一的标准，也就可以避免日后的那些整合工作了！（当然，标准的形成需要一个过程）。我觉得借鉴经验是对的，完全用js实现一遍java，设计成本是少了，但是实用意义有多大，目前还不得而知！我们拭目以待吧
当然，我非常乐意看到java（或者别的一门语言）能一统天下，那我们的日子就好过了！就可以专注于更高层面的东西了

重新看了一遍帖子内容，或许我把Java2Script扯进来讨论不算是什么。

总结一下我的认识，JSVM貌似关注一个比较单一的层次（加载*.js和cache以及4个不同模式），不太关注JS开发者的开发过程和进一步的类库开发模式。同时JSVM也感觉脱不了Java的模式，成了夹在Java和JavaScript之间的一种状态。

而我扯进的Java2Script是一种完成是从Java角度看待JavaScript的比较纯的技术。J2S设计的初衷与JSVM不在一个层次上。

但愿JSVM能够走好。

多谢 jossonsmith ！

接下来，我们讨论一下前面三人对谈中被反复提到的一个问题：

jsvm2 是否有过度设计？runtime.js 中提供对额外语法(#lanaguage jsvm2)的支持是否必要？
jsvm2对js模块化的解决方案是否过于臃肿？jsvm 是否有必要“减肥”，使得更轻量级一些！

庄表伟、dlee、醒来 对jsvm2这一块的设计提出了相同的质疑，认为额外的语法支持和被缺省打包在runtime.js中的那些api类，属于鸡肋！
我猜测，这显然是三位从实用角度出发得出的结论，这种怀疑的另外一个出发点是担心这种“不是很有必要”的设计影响jsvm2的性能。

我先看看这种设计是否对性能造成了影响，再来讨论一下这种设计的目的，看看是否是鸡肋。
因为是否对性能造成了影响，是判断为这种设计而付出的代价是否合算的重要依据!

release 2.02.060209 版本中的 runtime.js 大概 43k ,主要是将jsvm自带的那些api类编译后以string的形式直接内置在 JSVM 的 container 中。

于是，醒来对jsvm2自带的parser的性能产生怀疑，认为如果不编译可能会造成性能上很大的损失。其实这是一种误解。
当然，必须承认编译后会提高class的加载速度。但是由于parse额外语法而造成的性能损失其实是微不足道的。
这个可以通过一些实验数据来对比说明问题。对此仍然有怀疑的人不妨自己试一下。
其实，性能的瓶颈主要还是在IO这里，同步方式按需逐一加载的jsc文件过多才会真正造成性能问题。
而在runtime.js中这种集中批量加载的方式对性能的影响是可以忽略的。虽然它有43k,但是实际上用户感觉不到很大的差异.
另外一个很大的原因是：jsvm2有完善的cache机制，在第一次加载jsvm之后，系统以后都不会再去请求 除jsre.js之外 的所有核心文件，比如：kernel.js, runtime.js, application.js 等等。（如果是IE的话，即便重启IE，cache也依然存在）

以 http://jsvm.org/demo/ 为例!

进入某一个demo页面之后,你通过右键的方式刷新一下里面的页面,（之前启动HttpWatch，查看网络交互情况）
你会发现, 实际上页面只对jsvm2中的jsre.js文件做过请求. （可能返回的还是304的 Not-Modified,没有实际数据交互，直接取得Browser的cache）

xxxxxx GET 304 application/x-javascript http://jsvm.org/demo/jsvm2/jsre.js

这是因为jsvm2 对除jsre.js以外的所有文件都做过cache处理，尤其当应用程序模式时，除jsre.js之外的所有资源，包括jsvm本身的代码和js class代码都在application的内存中高速缓存。
其他所有的页面，只需加载 jsre.js 文件（6k）如果浏览器本身有缓存，这部分加载也是本地cache中的内容。
那所有那些 runtime.js 中的代码实际上并没有产生 IO 操作。

所以，对 runtime.js 中的设计是否造成性能上的损失，完全可以不必太担心！

注：一旦jsvm的版本发生变化，jsvm本身的cache也会自动更新！

（未完待续...）

如果jsvm只是提供_import支持，它对于我们还是有意义的。不过，我们不会使用jsc语法，也不需要js.dom等类，这些都应该是可选特征，希望发布一个简装版。应该补充一个非jsc语法的js类的sample

另：我们在服务器端采用模板机制并不是生成js, 服务器端封装的作用也不仅仅限于对于js的管理，还涉及到css，图片等资源，以及html与后台java对象的结合。

万常华同志还是很值得尊敬的。不过Web2.0让开发人员更加浮躁。老板今天看到某网站实现了什么奇妙的效果，明天就让开发者也在自己的网站用上。开发者除了到处找现成的代码以外，没有别的办法。这种状况养成了他们不肯自己去积累的习惯。我们很多所谓的架构师不过只是个粘贴拷贝的快手。
万常华同志长期以来孤军奋战，没有实现很多UI组件很容易理解。

如果有比较理想的开源解决方案，例如后台的Spring，我也坚决反对使用自己独创的架构。不过目前Ajax UI组件库的水平和数量还远未达到理想的状况。发展一套自己的架构是非常有现实意义的（共产主义尚未实现，谁能告诉我什么时候可以实现？明天还是后天？我是不是现在就可以睡大觉等到那一天的出现？）。