关于 jsvm 的争论

jsvm2 自带的jsvm2语法解析器的代码大小只有2k，jsvm2自带的那些api类，一是为了封装jsvm的内部细节（避免开发人员侵入到jsvm内部），如：js.lang.System ，二是为了屏蔽各种浏览器之间的差异。如：js.dom.StyleSheet, js.net.XmlHttp, js.net.XmlDom.
我何尝不想压缩这块，避免runtime.js过大，只是难以取舍，这些类要么是很小不占什么体积，要么就是实现了基础功能，使用频繁且非常有用。举几个例子：

js.lang.System：对 jsvm 本身的接口和部件作了一些封装，避免开发人员侵入到jsvm内部
js.lang.Exception： 异常的基类,作为一种推荐的规范
js.lang.RuntimeException： unchecked exception 的基类,作为一种推荐的规范
js.lang.StringBuffer：类似java.lang.StringBuffer,非常实用的一个String辅助类
js.net.XmlHttp： 对 ie,firefox,opera 下的 XmlHttpRequest 对象提供了一个统一的创建方式。屏蔽了不同浏览器之间差异
js.net.XmlDom： 对 ie,firefox,opera 下 Document 对象的接口进行了统一的封装。屏蔽了不同浏览器之间差异，
js.dom.StyleSheet： 对不同浏览器的StyleSheet进行的封装，这在以后的UI组件开发中非常有用。
js.dom.Window： 通过这个类可以将web页面通过类的方式进行封装：例如：某一个UI页面可以不用以.html文件的形式存在，而是以一个类的方式存在。
js.io.Serializer：对 js 对象的序列化与反序列化。这是一个平台必备的基本功能。
js.io.WebPrinter： 一个窗体输出对象，可以作为控制台输出用。
js.util.HashMap： 实现了 Object 类型作为  key 的 Hash 功能。 这在今后的组件开发中会非常有用。

你觉得哪些可以丢弃的? 给我一个建议！

另外，针对 jsvm 加载  kernel.js,  (ie|moz|opera).js , runtime.js 等核心文件, jsvm 采用了很多优化的方案,通过一些cache机制减少io操作.（性能问题关键在io，在代码的执行上不会产生瓶颈）

jsvm2 确实自己实现了一套面向对象的类继承模型，但是这没有强约束，只作为推荐方式用！ 目的是为了给开发人员足够的自由度，也是为了不致于让jsvm越走越偏,毕竟这个不是jsvm的根本目的,jsvm本身作为一个平台应该足够的灵活。
不至于限制了用户的创造力! 很多人的创造力，不是你我现在可以预料的，如果限制得太死，也会给平台本身造成损害！

我们不久将会推出一套功能比较丰富的工具类，如：StringUtil, DateFormat, HttpRequestCodec, URLEncoder, validator, dialog. 等等

上面不是单说你，也包括我本人。最近夫人想换手机，挑了个联想的，我第一句话就是：“联想的？不会用几天就坏掉吧？” 其实我此前并没有对联想的手机质量做过调查，凭主观上的印象就说了这么一句话！

并非要把jsvm打上made in china的标签，科学，技术、真理、都不分国界。
但我本人确实也希望看到国家和民族能强大起来，这首先需要建立自信，而且要更加团结，在很多方面。

对jsvm的评论各种都有，我向来不以为意，评对了，那是一个好的建议，我感谢还来不及，评错了，讨论一下也自然就清楚了。但对于一些出言不逊的人我当然也不会太客气！能心平气和，就事论事最好！若想冷嘲热讽，还不让人回讥，呵呵，这恐怕有点霸道，我也从来不吃这套！

Dorado 很早看到过，他的定位和aw，webfx 类似，定位在中间件产品的开发。而我觉得要想进行大规模的中间件开发，必须先搭建好一个平台。

另外，要澄清一个概念。并不是要你为jsvm做贡献。jsvm作为一个工具，他是来帮助你开发的。而不是要你为他开发更多的类库！你开发的东西与它无关。但有可能会从应用层面推动了它。当然你完全有权没有兴趣，这个我无所谓，呵呵

runtime.js 变得很大正是为了支持jsc的环境，prototype 可以比较自由的按需切割，而 jsc 无法作到，当然这样的设计是和jsvm的名字符合的。但是在js里用HashMap,StringBuffer 其实意义不太大，不如将核心的部分(比如System,XmlHttp) 用纯js 封装。

其实 jsc编译后的语法已经很清楚，面向对象的结构也很清晰了，我的建议是将jsc抛弃，再整理一下结构，将核心部分用纯js封装，然后随着大量工具类和组件的提供，jsvm是可以和dojo竞争的。

工具类和组件真的很重要，因为开发人员需要 jsdk，而不仅仅是一个 jsvm。

你的意思是，放弃 jsvm2 缺省的额外语法支持，那些自带的api类依然用单个jsc文件的方式存在, 并改成纯js的编码方式！
目的是减小runtime.js的体积或者干脆去掉runtime.js的加载，给jsvm瘦身？

我能理解你的这种想法，其实现在的版本不用改代码也能实现你所说的。
在 rtenv.conf 中，将 # runtime = runtime.js 去掉注视后改成一个新的文件(或者空文件)就可以了, 那些自带的api类,不去调用也不影响实际使用.
类似,jsvm中的很多部件都是可以重新设计并通过简单的配置就可以生效的.
jsvm的核心在 kernel.js + <platform>.js 文件中，其他例如：runtime.js，application.js module.js 都属于外围设施。

对 HashMap,StringBuffer的用处,我仍保留原先的看法。

比如：如果我们要实现两组 object 之间建立映射关系，并能通过key-object快速索引到对应的value-object，如何实现？

至于：StringBuffer ,可以通过一个例子来说明问题：

比较一下执行效率。

var t1 = new Date();
var s = "";
for (var i = 0; i < 10000; i++)
{
s += "xxxxxxx";
}
alert(new Date().getTime() - t1.getTime());



var t1 = new Date();
var sb = new StringBuffer();
for (var i = 0; i < 10000; i++)
{
sb.append("xxxxxxx");
}
var s = sb.toString();
alert(new Date().getTime() - t1.getTime());


当然，也可以直接通过数组来实现类似StringBuffer的功能，但是那样的代码不如现在这样简洁易懂吧! (尤其是当不在循环内部的时候)

分颜色的版本可以去我的blog

http://spaces.msn.com/zbw25/blog/cns!BD4EFBFAF436336C!903.entry

庄表伟 说:

JSVM，我觉得有一个方向可以尝试去发展，就是浏览器中的对象管理，起到一个VM的作用

dlee 说:

问题就是你敢不敢去做小白鼠，或者叫做生活在剃刀边上。对于一个严肃的项目，我做项目经理，是不会采用jsvm的。

庄表伟 说:

那为什么你就会采用prototype呢？

dlee 说:

prototype背后有强大的支持，而不是像jsvm那样只有万常华同志等很少的几个铁杆。

庄表伟 说:

为什么？你是看着哪边人多去哪边的吗？

dlee 说:

你看那些叫喊"顶"、"支持"、"牛"的人会不会贡献一行代码。你太容易非黑即白了。当然不完全是这样，不过支持能力是一个非常重要的考虑因素。

庄表伟 说:

我的意思是，JSVM，该不该用他，只能由我们看过他的代码以后，来决定？

dlee 说:

你有能力维护所有的代码吗？

庄表伟 说:

我只是用他呀，又不是要改他

dlee 说:

我的意思是说，如果你在项目中使用了Spring，Rod Johnson玩累了，明天就宣布解散这个项目。你自己独立去维护Spring的代码。你去用什么啊，它只有很少的UI组件，其中还有问题。 你不要夸口这些自己都能开发好，我两年前开发了一个比较好用的Grid，花费了一周多的时间。你自己去实现这样一个组件后再说话。

庄表伟 说:

我不是用他的UI呀，而是用他的这个框架，来组织自己的代码。

dlee 说:

你不用它的UI，有什么必要使用这个框架呢？dojo/prototype一样可以做到啊，我是认为你这样做引入了不必要的成本。况且你如何判定使用的UI库在设计理念上与jsvm完全没有冲突？

庄表伟 说:

OK，你现在已经有结论了，但是我还没有仔细看过他的代码呢，所以我现在还没有结论，等我看过以后，自然会有一个结论的。

dlee 说:

在Ajax库这方面，大部分人都跟我希望的一样，需要一个全面的解决方案。你说的jsvm专精于做某个领域，我认为是行不通的。任何运行于浏览器的js框架都应该是为UI服务的。没有实现过很多UI组件，如何检验它的这个架构设计的合理性？

庄表伟 说:

目前看来，prototype，也只是专精于基础领域的，在它之上，另有script.aculo.us、Rico、Behaviour这样的lib

dlee 说:

你喜欢摆擂台，那么就摆个擂台，大家都实现Grid组件，看看谁做得好。

庄表伟 说:

呵呵，这倒是个好办法

dlee 说:

你可以跟醒来来详细讨论，问题不是你想想得那么简单。做小白鼠也有好处，晓钢就经常偷偷练习一些自己的独门绝技。

庄表伟 说:

呵呵

dlee 说:

你可以将我跟他的冲突理解为主要在一个领域，就是我不认为解决他所说的两个问题，需要这么重的方案。而且他的解决方案从JS开发者的角度看来也不是很优雅。

庄表伟 说:

嗯，这两点，我基本上是同意的

dlee 说:

万常华同志的兴趣不在UI组件方面，这使得他偏离了浏览器JS诞生的使命。今天我跟醒来说过类似的意思。 我们的分歧不完全在技术本身上面。因为我们思考问题的思路差别很大，所以没有出现很大的交集

庄表伟 说:

嗯，我比较理解你的意思了，但是，我不是很同意...

dlee 说:

你看过他们的代码了吗？

庄表伟 说:

看了一些

dlee 说:

代码的模块程度如何？有没有可能将醒来说的一些部分完全去掉？

庄表伟 说:

哪些部分？

dlee 说:

我觉得他们如果做一些更加清晰的划分，划分出一个最小的core部分，而且像Spring那样划分成很多不同的jar，这样会更好一些。最糟的情况是要么全有要么全无

 

  醒来 已经添加到此对话中。

 

dlee 说:

你既然对jsvm非常感兴趣，就和醒来先详细谈谈。我作为旁听好了。

庄表伟 说:

呵呵，好的呀

醒来 说:

好啊，我 最近刚看了jsvm的源码

庄，你觉得jsvm怎么样

庄表伟 说:

我刚开始看他的代码。说实话，我觉得他的js代码写得非常好，也很干净、清楚。因此，这样的一个人，写出这样水平的代码的人，对于js的理解，肯定是相当深入的。

醒来 说:

代码写的是真不错

庄表伟 说:

我以前曾经想当然的认为，他不了解js，只喜欢java，所以才会把js，扭曲成java的样子这样的想法，肯定是偏见。那么，在承认对方有足够的智力与经验的前提下，再来看他的代码，我觉得更不该"断然否定"，说他"一无是处"。

醒来 说:

我在javaeye 上提出了我的意见，我也认为他的代码写得很不错，但是侧重点有点不合时宜。现在真是有些像java虚拟机了，基本是一个classloader + class cache 的实现

庄表伟 说:

还有这个：

a) 独立模式：standalone, 该模式下，当前页面的jsvm独立加载，不和系统中其他页面的JSVM发生关联。

b) 应用程序模式：application, 应用程序模式下的页面会除了加载jsvm以外，还将构造一个Application的环境。其他模块模式的页面会共享Application的资源。

c) 模块模式：module, 模块模式的页面必须运行在一个Application模式的页面下。该页面可以通过application框架共享资源以及访问全局变量。

d) 自动模式：auto, 页面根据环境自动选择是独立模式还是模块模式。

我觉得很有点意思

醒来 说:

从名字上来讲，jsvm倒是符合本意。但是java的成功不是只靠一个jvm的，我觉得 jdk 更关键

庄表伟 说:

现在的js库，除了jsvm，都是以一个Page为单位运行的，鲜有"Application"的概念。而VM的提出，我认为，为将来合理的Browser Object Cache Layer，提供了可能

醒来 说:

我有点怀疑，这样带来的复杂性有没有必要

庄表伟 说:

而且我还希望将来JSVM，能够更好的支持请求任务队列的管理，这样的机制，JS的语法本身提供得并不够好。还有多线程的管理，JS也没有像Java那样的，语法级的支持。

dlee 说:

我不大相信浏览器中的JS将来会被用在这样的目的

醒来 说:

其实我觉得，这些应该是浏览器提供的功能，在浏览器未发展到这个程度之前，强迫javascript畸形的实现，不一定值得

庄表伟 说:

嗯，这是问题的关键...我前面的畅想，的确是我希望将来的JS，能够支持的一部分

dlee 说:

是的，我们希望将来的JS引擎来提供这些基础设施

庄表伟 说:

现在JSVM，也许能够支持一部分，也许还不能够，所以，说不定哪天JS 2.0出来，JSVM就没有意义了

醒来 说:

所以对于jsvm的模式，应用程序模式还可以理解，模块模式很难让人明白有什么用

庄表伟 说:

这是一个思考模式的问题

假设你对于js本身不熟悉，要让你合理、自然的划分多个js文件，合理、自然的在该load的时候才去load，这就相当的费力

醒来 说:

所以我的意见就是，jsvm 希望吸引人来开发，应该要给出jsdk 差不多，一个jsvm 吸引不了人

庄表伟 说:

当然，更加正确的道路，当然是按照js的本性来做，提出某种"js loading design pattener"。但是，在经验还没有被总结成模式之前，模仿java式的代码组织，不失为一种方案

醒来 说:

load js 的模式其实现在都是 用一个同步的xmlhttprequest 去加载js,然后eval。这个 dojo 和 prototype 都有提供基础支持

庄表伟 说:

不是如何loading。而是，我现在有几百K的js文件，如何切分成合理的大小，然后在需要的时候去调用他们

醒来 说:

这个想法是对的，也是jsvm值得肯定的地方

我的主要意见是说它提供的 jsc 的形式有点鸡肋，同时缺乏简单高效的工具类，所以吸引不了开发人员。jsvm2 的代码里有 1/3 就是为了支持这个自创的jsc语法

庄表伟 说:

这是...败笔...。jsc我也不喜欢，混杂了部分js语法和部分java语法...还不如仅仅规定一个必须的头部，其他的完全采用js语法呢。还有一点我觉得是这个万兄在那里畅想，就是JSVM打算支持多种语法的设想，工作量太大了。

dlee 说:

不过万常华同志说这个可以不用

醒来 说:

所以我建议索性抛弃jsc，以万兄的javascript功力，写一部分有用的工具类，我觉得不会有人真的愿意用 var map = new HashMap(), map.put(k, v); 这样的方式写js

庄表伟 说:

对的

dlee 说:

所以我刚才说：

我觉得他们如果做一些更加清晰的划分，划分出一个最小的core部分，而且像Spring那样划分成很多不同的jar，这样会更好一些。最糟的情况是要么全有要么全无。

醒来 说:

jsc 是可以不用，但jsvm 加载了接近80k的js就为了支持jsc, 没有意义啊

庄表伟 说:

他现在是有多个js的，只是他core的部分太大了

醒来 说:

庄，如果你去看runtime.js 就知道了，jsvm2其实把jsc都预先编译了，否则效率一定太低

现在甚至还有一些观点，不要把js分得太多，因为要激发太多的http连接，反而响应性更不好。毕竟js的加载是同步的 ，这各ajax的异步核心思想有冲突。

dlee 说:

这个考虑也是很有道理的

庄表伟 说:

激发太多的http连接？还是激发太多的同步http连接？

dlee 说:

那个所谓的classloader就是向服务器请求一个包含js类的文件，然后evaluate。而且也要考虑evaluate的执行效率

醒来 说:

每一个import 就是一个http 连接。当然，jsvm 考虑到了cache

dlee 说:

对的，就是发出一个xmlhttp请求

庄表伟 说:

其实，他完全可以将自己的jsdk，做成一个jsc文件，一口气load进来

dlee 说:

不是多个连接，这个要看服务器怎么配置。其实支持http1.1的浏览器和服务器都是保持长连接

醒来 说:

jsvm的cache 也有些问题，他所谓的application模式，在不同的浏览器上实现各不相同，ie是js源码用ie的htc 技术保存的，ff 是存cookie。cookie 的容量是有限制的，所以cache 主要是针对 ie。

dlee 说:

可能是在同一个http连接上发送多个http请求，这些请求需要排队

庄表伟 说:

OK，我提一个方案，你们看是不是可以作为"最佳实践"之一：

对于多个异步请求，可以让他分次异步提交。

对于多个同步请求，应该将多个请求打包以后一次提交。

这个作为"请求队列管理"的一部分

醒来 说:

道理应该是这样，jsvm里好像没有这样的控制，import语句也没有这么智能

庄表伟 说:

其实jsvm应该这么做，比如他load一个jsc文件进来，里面的import语句可能有一堆，就应该是一口气load其他的jsc，不该再分多次了

醒来 说:

我总觉得 线程/队列 这些该是浏览器的事情，用js开发很不保险

庄表伟 说:

你看过我写的那个RSSReader的代码吗？里面就有一个请求队列的

醒来 说:

jsvm做不到，因为load的jsc里又有import 语句，这是递归的

庄表伟 说:

不是递归，是分层的

醒来 说:

要么js语言升级，要么浏览器升级，我总觉得现阶段就想让ajax完全达到替代桌面应用的程度是不可能的

庄表伟 说:

这个当然是不可能的...

醒来 说:

所以在现阶段，还是不要搞复杂了，多线程和队列能用到的地方毕竟不多

我觉得dlee强调的对的，现在需要的是组件

语言级别的东西，就让js语言和浏览器标准去慢慢支持吧

庄表伟 说:

我理解你们所认为的"轻重缓急"了。根本的观点在于："急于将浏览器中应用，推向完全的桌面应用，并不现实"。立足于"更好的浏览器端应用"，而非"尽可能像桌面应用的浏览器端应用"，这么说来，当务之急自然是UI控件的完善与丰富

dlee 说:

我觉得浏览器中js诞生的使命就是改善交互和UI

醒来 说:

对，就是这个意思

dlee 说:

而且我从项目开发负责人的角度，更希望一个全面的解决方案。不是什么都需要我去做集成

庄表伟 说:

JSVM的问题，不在于他语法上像Java，而在于他的目标上像Java！

dlee 说:

也可以这样来理解

醒来 说:

ajax 里的cache 应该是去cache 数据，用来cache js代码，意义多大呢，所以jsvm太技术化了

dlee 说:

在Ajax in Action中，提出了一种独占式应用。就是像Word一样，可能每天都要用上几个小时。目前的Ajax技术，包括一些基础框架，还很难达到这个要求。所以确实需要这样一类基础架构，但是我们认为这些支持最好由浏览器和JS引擎来提供。

庄表伟 说:

看来我们已经初步达成共识了

醒来 说:

js 就是用来操作DOM的，不要让它承担太多重任，xmlhttp本来也不是 js的一部分，浏览器的扩展而以

dlee 说:

我发现现在很多人有一个通病。就跟我在那个ajax和model2框架的讨论中说的那样。毫不思考地就将一种技术或者架构用于设计意图之外的场合。其实把IFrame用于异步请求也是这个情况

醒来 说:

对jsvm 的建议就是抛弃jsc，完善它自己的面向对象架构，并提供工具类支持，这样才有可能和 dojo 有竞争。所以在国外是称为  tricks,  是有贬义的意思，但翻译成中文，变成窍门，反而有了褒义了

dlee 说:

Ajax in Action的作者称作hacky的做法，带有贬义

dlee 说:

令Ajax显得与众不同的地方不是它所使用的技术本身，而是通过使用这些技术所带来的新的交互模式。我们所习惯的传统的Web交互模型并不适合于独占式的应用，只有打破了这种交互模型，新的可能性才会慢慢浮现出来。

这是Ajax in Action的一句话，说得非常有道理。我们看到如此众多的人都对Ajax感兴趣不是偶然的。现在我们处在web app发生革命性变化的前夕

庄表伟 说:

嗯，我更关注：慢慢浮现出来的这些可能性中，哪些是正道，哪些是邪道

醒来 说:

我是觉得一定要擦亮眼睛，多从用户的角度想问题

庄表伟 说:

这是对的

完整的看了一遍三位的对谈，其中非常赞同庄兄的一句话，那就是大家在这里讨论问题，必须在“承认对方有足够的智力与经验的前提下” 否则很定会被一些简单的问题困扰，讨论迟迟不得深入！

不过我这里还要强调一件事情：jsvm 从 jsvm1 （一个很小的 core） 到如今“看上去很重量级”的样子，发展历程是怎样过来的。 从我脑海中jsvm的雏形到后来有点东西拿到网上来讨论再到如今jsvm2 已经历经3年多的时间！你们刚才讨论中谈到的多数问题都是我在设计jsvm2的时候遇到过并且反复考量过的。但最终还是决定了jsvm2如今这种架构！所以jsvm2是一个深思熟虑的产品，而不是像jsvm1那样草草拿出来作可研论证的。jsvm2所有环节的设计都有他的考虑的，因为我做事的原则是：凡是可有可无的东西，我向来是选择抛弃。从我的角度，看你们刚才的谈话，我只能说，三位对jsvm的思想了解了一半多一点（其中仍然存在一些误解）。剩下的这一半少一点，我想可以在接下来的几天做更深一步探讨。等大家完全了解我对jsvm2的设计思想之后，那时候再来做一个全局完整的结论，看看哪些是可取的，哪些需要改进！

像像很多人一样，我是从做传统c/s开发过来的人，对b/s的本质和底层细节比较清楚，所以很早就发现b/s在交互方式上的不合理性，几年前我在和周围同事推荐用如今ajax方式设计应用时（那时候还没有ajax这个名词，最早是通过隐藏的iframe来作为与服务器交互数据的通道），几乎得不到什么人的支持，大家都沉醉于j2ee的狂热中。

今天太累了，先到这吧 ... (待续)

还有件事: dlee 作风似乎不太严谨？ 没有弄清楚我真实姓名就用wch3116好了，怎么还替我造了一个名字，万春华是谁？ “万常华”此名乃祖父授之，本人都不敢改，你怎么就这么轻率给我改了呢？ 呵呵! 另外，你喜欢揣测别人的思想，这一点我觉得需要慎重，就目前看，你很多对我的想法的揣测都是错误的！关于这些我们后面慢慢讨论！

精彩啊精彩。

老早在51js上接触jsvm，也看了看当时的代码。jsvm2没看过，暂时也不想看。
说说我的理解。
    jsvm应该是个底层的东西，我认为它主要是为别的javascript工程师服务的。  
   如果我项目中用了ActiveWidgets等其他很多”组件“，我根本不会用jsvm。prototype.js我是会用的，它提供的Form,Element等基础功能还是很不错。Class.create() 我也不用，我觉得Class.create()和 jsvm提供的某些功能一样，例如Map,List实现，只能算很像java代码,好看点吧。
   如果我们公司要开发一套类似ActiveWidgets等一整套UI组件的东东。可能我会考虑jsvm的。我始终认为它主要是为别的javascript工程师服务的。  



我相信同一个人，如dlee， 用jsvm 或 用prototype 或者什么类库也不用。开发出来的Grid是一样的。看这个人js水平怎么样。


我觉得他的兴趣在   在开发UI组件的人身上。 


我不知道这该怎么实现，就我对js的理解来看，实现它没什么意义。
有两点疑问：
1。js的执行环境是以一个htm为单位了，每个页面会建立全局的执行环境。（frame,iframe可以相互访问）
2。如果我的所有js代码都用了jsvm   import功能。我每个页面是不是应该首先把基础类库的n个<script src ="....">下载啊。我绝对不会这么干

为了实现js的模块化而实现一种新的前台语法，我认为有些过于严重了。目前前台技术处在激烈的变化过程中，我们的做法是尽量回避前台技术发展的不确定性，而通过后台tpl模板集成各类js库。 jsvm的设计过大，有些独占性，但是它又没有提供足够吸引人的组件，我想这对它的发展是有很大限制的。

如果就JSC的方面来说，其实J2S（Java2Script：http://j2s.sourceforge.net/或者http://sourceforge.net/projects/j2s/），已经支持了95%+的Java语法，而且还完整地集成了Eclipse的JDT功能，同时还直接由JDK的java.util.*生成对应的类库。由于直接站在Eclipse&JDT的巨人肩上，同时直接复用大量的Java代码和工具，这J2S就要远比JSVM要来得好了。