关于 jsvm 的争论

看看这个吧

【分享】基本上实现 javascript 的 OOP (0423版)

很强。作者用js实现java类库。

有几个问题，请多指教。

(1) 我看到 js代码中有这样的代码。

_package("js.graphics");

_import("js.lang.Object");
_import("js.graphics.Point");

不知道是不是java script的标准语法？

(2) 看到每个目录下，都有一个package.xml文件。
lib目录下还有 .hta文件，和lib-inf.xml文件。
还看到代码中调用了 XMLHTTP, 还调用了 一些ActiveX控件。

不知道这些js的运行环境要求如何？
我只知道，hta和XMLHTTP都是微软的技术。不知道这两者之间的联系如何？

多谢。

呵呵，51js 可比我们这里热多了。
那个东西完全模拟 Java 的工作方式，我不大喜欢，毕竟 JS 与 Java 的差异还是非常大的。我如果不喜欢 Python 的语法，用 Python 实现一套类似 Java 的语法可以吗？当然可以，但是我认为没有必要。我还有更重要的事情要去做。
作者对 XMLHTTP 似乎是大材小用了，用来实现一个所谓的 ClassLoader。另外用 JS 实现一个所谓的 RMI 更是有些滑稽。显然作者是 Java 老手，太过迷恋于 Java 的开发方式了。可是写 JS 的还有服务器端用 ASP、PHP 的，未必会喜欢这种编程风格。不仅如此，还增加了学习成本不是？我读了《JavaScript 权威指南》还要再去学习他的一套语法，我累不累啊？JavaScript 最大的优点就是上手容易，便于测试，作者把这些优点抛弃掉了。我最喜欢的格言还是 KISS。由俭入奢易，由奢入俭难。我确实很傻，学不会他那个东西。拜托，你就让我一直傻下去不行吗？
基本上是重新发明轮子，没有多少价值。当然作者的 JS 确实写的很漂亮，值得我们学习。

看了这个帖子才知道这个好东西。我你批评这个jsvm的话我看都有点站不住脚。KISS也不是放之四海皆准的真理，简单到一盘散沙就不好了，javascript/vbscript出来这么多年了，却还是老样子，大家各自为战，没有一个统一的世界，只怕到最后是View这一层最花功夫却又是事倍功半！

他们在向一个规范，标准努力，至于新的语法那是不可避免的，因为根本就是从零开始！已经是在尽可能的利用大家熟悉的语法来降低学习曲线了。

我看他们考虑的方向的价值远大于写得漂亮的代码。《JavaScript 权威指南》只不过相当于战术，我们现在更需要战略层次上的东西。

你怎么知道别人就没有战略？《JavaScript 权威指南》当然只是一本入门的书，我什么时候把这本书捧上天去了？但是不客气地说实际上很多人最需要的还是把这些基础知识打牢。漂亮话很容易说，真正复杂的东西你做得来吗？

我的观点已经和朋友讨论过了。就是我们其实更需要的是一个与 HTML 结合得很好的开发框架和一系列的控件，而不是一个重复发明轮子的新的 Java 类库。JavaScript 与 Java 只是语法上相似，其实有着本质上的区别，一定要以 Java 的方式来做 JavaScript 开发有什么好处？况且这个 jsvm 还没有与 HTML、XML、XMLHTTP 很好地结合起来。

我们需要的是 Bindows 或者 htmlArea 一类的东西。这个框架甚至不一定要是 100% 面向对象的，只要好用、能够改善用户界面、提高我们的开发效率就足够了。

同意dlee。js需要统一的框架，但是靠照抄java，jdk来找灵感，不是正路。

上次我还和dlee聊过，js有些特性是java不具备的，比如要在js上实现AOP，要比java上方便很多，这其实是一个很有意义的方向。

再者，js是面向显示层的，jsvm的很多东西，照抄jdk，却没有考虑显示层的特性。

我看微软迟早要把那些缺乏的特性加上去，jsvm是在目前恶劣的开发环境下的一个很有意义的尝试。我倒没看到还什么更好的所谓的正路。

要是有友善的开发环境，不要说Bindows，可能现在XYZindows都有了，而不像现在只有少数几家公司做出来那些还要收费的产品，而且不同的产品都有自己一套讲究，晕。

想象一下如果能做到像java那样的api那种标准，一目了然的调用，无论是开发还是使用，效率都很高，可以想象共享资源这一块领域的发展速度一定是现在的10乃至100倍以上。

呵呵，看了诸位对jsvm的讨论，偶对这个东东也甚有兴趣，并与其作者交流过。下面说说我的看法：

早先我和dlee的想法类似，觉得jsvm中的一些类库照搬jdk有些牵强，并不是非常合适，后来对jsvm整个架构设计与作者交流中发现原来自己理解上有一些偏差，到后来我就比较赞成 lllyq 的看法了。

jsvm本身提供的规范是相当少的，某种意义上只对js 代码的组织结构形式进行了要求。
目的是：使js 代码可以有良好的组织结构，能定义明确的依赖关系。它其实是一个较抽象的框架，定义了一些基本接口，并对这些接口给了一些缺省的实现。其实我们可以针对这些接口重新定义一些实现的。

你们和我一样，开始过多看那个所谓 “核心类库”的具体实现了，而忽略了整个jsvm的架构。
jsvm 本身并不依赖那个 “js 核心类库”，那个类似jdk的“js 核心类库”其实是作者在jsvm规范下给的一个实现样例。提供了一些较基础的数据结构实现类和一些基本的工具类。他希望这些类能给后来的具体开发提供一些帮助。

作者希望借助这个规范，使任意两个人写的js代码，不用做任何改动，放在一起就能用，而且不会有任何冲突。以实现js的重用性。
这才是jsvm的核心思想。过多关心那个 “js核心类库”，其实是注意力用错了方向，误导了很多人以为jsvm就是提供一个类库给人用。
其实他制定的是一个规范，希望大家遵循。

至于OO的那些规范，其实是可选的，并没有强制要求你必须遵循。我们可以写一个简单的不用继承任何超类的类。

作者的rmi其实就是RPC的一种实现，他更偏向通过现有的SOAP协议与WebService实现B/S之间的数据交互。至于那个rmi。我看就是纯粹为了在jsp和asp中使用－－在没有webservice的条件下实现b－>s之间的rpc。
作者留下了更大的空间，让大家扩充自己的类库。他看得比我们更宏观更长远。这一点我确实佩服！

理解不对之处欢迎指正！

这个观点是有些可疑的。其实要做到这一点，有更简单的方法的。我觉得编程规范和统一的代码风格已经足够保证这一点了（我们也确实做到了）。没有必要一定要模仿 Java 的开发方式（这其中也许还会付出一些性能的代价，不过这个不是非常大的问题）。

作者对于 JS 在整个 B/S 开发技术中扮演的角色的理解有些偏差。他的野心很大，似乎想用 JS 做一切事情，例如设计出那个 JS 的 RMI 和 JS 的 IO。但是 JS 的强项在于做表示层开发（展示），与 HTML+CSS 相结合，处理 HTML、XML 以实现更好的交互和界面。作者花了很大的精力去做与此无关的一些事情，真正与 HTML 相结合的工作却做的不多（我想这是他下一阶段需要重点开展的工作），所以这个框架对于我们这些普通开发者来说只是有潜在的价值，但是不是在手边立即可用的。你可以看看我写的一个 JS+XMLHTTP 框架所需要的哪些控件来更深入地理解我的想法。我的想法总结起来就是三条：
1、有更简单的方法来达到作者希望达到的目标。作者的这个框架某种程度上破坏了 JS 的简单性（让 JS 不象 JS 了，这其中的学习成本是要考虑的）。
2、作者对于 JS 在整个 B/S 开发中的角色的定位与我不同，我个人认为他的理解有些偏差。
3、JS 要充分发挥作用，提高开发效率，就一定要与服务器端的某种架构结合起来，形成联动。与服务器不发生任何关系的单纯的 JS 的作用是有限的。作者的这个框架中是使用 JS 实现的 RMI 来与服务器进行交互的（是否还有其它方式，请指正）。但是这样做有一些缺点，最大的缺点就是破坏了分层，让表示层与业务层发生了很强的耦合（我们知道 RMI 其实只是一个远程方法的代理，即一个 proxy 模式）。其实 SOAP 这类基于消息的调用机制应该会更好些（耦合要松的多），基于 XMLHTTP 建造类似于 SOAP 的调用机制比建造类似于 RMI 的调用机制要更容易，因为 XMLHTTP 本身就是基于消息的。我的看法是 B/S 之间传递的应该全部都是 XML 格式的消息和数据，而不是方法调用。

以上理解是否恰当，希望大家指正。

我们现在基于 JS+XMLHTTP 也在开发一个开源的框架，也许可以借鉴一些 jsvm 的经验。jsvm 目前采用的 License 还不大清楚，请楼上的解释一下好吗？

感觉没多少意义，回顾OOP的意义，在于更有效的控制代码。对于JS这种简单的Script，不一定要为了OO而OO。

我个人更看到它在view层的control的重用，和风格的可定制，至于OO，反而次要多了。

对于JS，我觉得就是just keep it simple, script就是script.