关于 jsvm 的争论

ray_linn 的意见不敢苟同，道不同不相为谋，没有讨论的必要。
dlee 说的：js主要处理表示层的工作，这一点我想大家看法是一致的。但随着richclient模式的发展，表示层的逻辑会越来越复杂，这样就会需要一些基本的数据结构类来辅助client端的设计，首先提供了这些类，我个人认为是需要的。
至于你说的如果将js与html,css,xml等结合起来，我想，他把这些留给了后人来具体实现，或者他接下来可能会提供一套基于jsvm规范的这类lib。远程调用我觉得还是非常有用的，不管是rmi或者webservice，只是表现形式上不同，但都是这种思想。如果一个url返回的是一个xml，rpc的返回结果（String）也可以是xml，这并不矛盾。而且rpc的接口定义会非常明晰。B、S之间的构建之间，用远程调用方式定义接口也不为一条好路。
如果组织jscode，来实现jsvm现在类似的功能，我确实还没有看到有别的更好的方法。
关于jsvm的license我也不太清楚！没看见有地方有说明介绍

工欲善其事，必先利其器！dlee 当初指点江山，激扬文字，可惜误解甚远！

别怪我揪住你不放。虽然你只说了一句话，好像很机灵的样子。:lol:
你们若真的懂JavaScript的话，就不应该单纯模仿Java的开发模式。没错，dojo同样也实现了自己的继承体系，也定义了自己的类似于package的机制。prototype同样也做了类似的工作。但是他们的出发点都是为了解决我所说的JavaScript现存的两个主要的缺陷。
http://forum.iteye.com/viewtopic.php?t=8630
并且在很好地解决了这两个问题之后，把关注的重点都集中到了丰富的UI组件上面（prototype的UI组件由Rico等项目来提供）。而不是像jsvm那样走火入魔地企图实现Java核心类库，然后完全模仿Java的方式来做JavaScript开发。jsvm的开发者几乎根本就没有开发出什么有实用价值的UI组件来，正是因为他们最初就把路走偏了，结果越走越远陷入了泥潭。抛开他们不完全理解Web标准，他们连对JavaScript这门语言本身的理解都是很可疑的。这些深层次的问题并不能因为他们动机完全正确和善良就一笔勾销。
JavaScript与Java差别不大吗？只有才学习了两天JavaScript初学者会这样想。建议你们都去仔细读一下《Ajax in Action》的附录B，就会清楚为何单纯模仿Java的开发方式是有害无益的。
这个问题我还会在这里大张旗鼓地说下去。

想当然地臆断，往往是错误的，没有调查就没有发言权。这个道理大家都应该知道！

不是什么东西你看一眼就能看透的！你对jsvm的了解非常有限，而且你的理解和我的初衷相差甚远！另外，你不用建议谁读这个读那个，似乎你读过很多书！但实际上昨天看完你的几篇帖子之后，除了觉得你过于自信之外，还没有别的什么感觉！

to wch3116：
那你就把你们的道理仔细说来听听，这样对于我和这里的网友都会很有帮助。不要只会在这里发出几声冷笑。

当初设计jsvm不是为了让javascript去单纯模仿java的模式！你看到的那只是表面， jsvm1 中自带的“js类” 只是一些 demo class 而已，因为jsvm1是jsvm的可研论证阶段，所以写一些简单的类来作示例，看看这种方案的可行性。java为人们所熟知，所以就采用了一些类似java核心类的划分方式。现在回想，在这个问题上是犯了错误的，导致让很多人造成了误解！

诸位都是经验丰富的人，我们下面就js开发过程中的根本问题进行讨论，那些细枝末节和次要矛盾这里就不谈了。

我个人以为：对javascript开发者而言，javascript的致命缺陷不在于它是否面向对象，是否能继承，采用何种复用方式，或者样子长得像java还是像c#。因为基于javascript本身的动态特征，上面那些都不会成为主要问题！（有些形式上的东西不是说一点不重要，但不是最重要）。我觉得js开发的最大矛盾在于下面二点：

1. 代码之间的依赖关系不能自动维护。
我们知道：设计时，代码的粒度必须合理，这直接影响复用性，其次，代码的存放（指文件）粒度也必须合理，这影响加载的性能！我们不能因为要用到一个function或者class，而去加载整个lib文件的所有代码。本着重用的原则,同一个function或者class也不应该在多个lib文件中出现，然而,传统方式中，跨文件域的依赖会导致必须手工去维护js文件之间的依赖关系（包括加载顺序）或者重新组织代码，后者更是不可取的。甚至，有一些依赖关系是运行时动态决定的，而我们将不得不将所有可能用到的code都事先加载进来。这显然无法适当大规模的应用开发。（有人可能会质疑：按需加载，加载粒度太小，太频繁，会不会影响性能，这些问题jsvm都有了充分考虑和解决方案）

2. 代码的命名空间和语法域（作用域）必须独立。这是为了避免来自不同地方的代码之间可能的冲突。

jsvm 就是为了解决上面两个核心问题而设计的。

这里有最新的版本和介绍：http://jsvm.org/forums/
WebFx，ActiveWidget，Yahoo UI Library. JSON-RPC, XML-RPC 等 for jsvm2 的版本上面也有下载。
（W3C DOM LeveL 2 的 Interface Lib 也已经完成，但尚未发布）
我想通过一些实例应该很容易看出jsvm的定位，走的并非是你想象中的那条路！（我的初衷从来都不是你想象中的那种想法）

另外：我从来不冷笑，我向来认为人的智慧有限，对世界的认识还很浅。所以我反对自我膨胀和冷嘲热讽!多一些交流，多一些进步！

wch3116 老万 是jsvm的贡献者之一啊
Thank you for your great job!
虽然还没用上，不过我在写一些复杂的javascript的时候的确发现你说的这些问题。
jsvm是国人搞的，我觉得这本身是件值得骄傲的事情，我觉得大家应该更多得提一些建设性的意见，有帮助的意见。

wch3116就是JSVM2的作者，不仅仅是贡献者这么简单吧。
我感觉dlee的想法就是有统一的编码规范就足以在team之内保证JS的组织问题。而wch3116提到的粒度问题确实以前没有一个基础设置能够有效地按需加载。我感觉JSVM2的规范能够推广开，所有JS贡献者都能在此基础上开发的感觉还是有一定意义，否则现在要在页面里面引入好多xxx.JS 不同框架的类库。
继续看去，现在正在JSVM的叶子里面泡着看呢……

是的，我们还是需要多交流。我们最初的讨论也都是针对jsvm1的，当时还没有多少可用的UI组件，而一个JS/Ajax库没有UI组件是很难吸引开发人员来使用的（JS开发人员通常都很忙，并没有很多时间来深入研究各种库和框架，更希望能够很快用在UI开发上）。jsvm1的设计确实太容易让人联想到Java了，这会造成很大的问题。
对于JS的缺陷我仍然存有不同的看法。我所说的两个问题严重阻碍了建造大型的Ajax应用。现在dojo、prototype甚至包括jsvm都已经很好地解决了这个问题，随后我认为jsvm在这些竞争者的压力下，要想突围而出，建造丰富的UI组件已经成为一个非常迫切的任务。希望我们能够很快看到jsvm在这个方面取得很大的进展。
另外还有一个比较重要的问题，就是在现在这些开源的Ajax库所提供的UI组件不够丰富的时候，很多时候必须要使用多个库所提供的功能。jsvm是否可以允许开发者方便地集成第三方库，也需要在这里解释一下。

好东西需要推广啊，
wch3116 能不能整理个关于jsvm的文档，贴在这个板块，做个精华贴