关于 jsvm 的争论

我离不开js的debugger，jsc如何debug?， 未来的IDE的支持呢？

我的意思是，jsvm2实现了一个jsc解释器，我猜测作者最初的想法是希望jsvm象asp一样可以用多种语言编写，所以jsvm既支持js语法，也提供一套便于java程序员接受的jsc语法。不过jsc混合了java和js的语法，有些不伦不类，看起来jsc有些鸡肋的感觉。

既然jsc可以直接用js语法，而且也并不难以阅读，甚至从性能上考虑，jsvm2的实现里内置的class也有直接用js语法。所以建议作者不如索性放弃jsc的形式。将package和import的架构再设计得友好一点。

一个框架容易被人接受，与其让它相似于大家熟悉的语言，不如让它更简单。prototype的受欢迎的原因就在于此。

有点像activewidgets1的样子，过度封装。。。

以前听说过，一看这个名字就没了兴趣，今天正好看到讨论地这么热闹。。。于是载下来看了看。
说明：只是看了看，所以以下的言论也只是看了看的结果，我不对此做任何解释，你们要骂就骂好了。
首先，听到这个名字我就觉得不伦不类的，看了代码后就更加觉得不伦不类了。。。特别是那个hello world的example。语法上那个乱啊。
其次，看到了example我就又想起了activewidgets，太像了。。。。连错误也犯得差不多，原本很简单的功能都要封装成object，弄得很复杂。何必呢。
还有，主页上号称支持firefox1的，我在fedora下面用firefox1.5只有两个例子能跑。。。虚假广告啊。

jsvm 是作为一个平台来设计的（一个提供“js类”加载、“编译”、执行的一个容器），他专注于javascript code模块化设计和组织规范，不关心这些“js类”本身是做什么用的。当然，这种规范很简单：每一个模块（jsc文件）有独立的语法空间和命名空间，通常情况下对外界只暴露一个公开的访问点 --- 类名（这个访问点类型必须是function）。模块在设计的时候可以通过jsvm提供的API:_$import() 来自行维护与其它模块之间的依赖关系。jsvm本质上只有这点东西。
另外，UI、Ajax 组件库 都不属于 jsvm 本身的范畴。他们作为上层的应用开发，或者是中间件开发。当然，你说的没错，如果仅是一个平台，上面什么现成可用的东西都没有，自然就没什么人去用了！目前已经有不少同志在努力开发这一块了。
jsvm采用BSD授权协议，对任何使用方式都不作限制。

jsc 的 debug 一样可以，只不过调试时它的代码显示在 eval 中。 IDE的支持是未来的计划，我此前做了一小部分，后因为认为这不是最紧迫最要紧的事情加上工作量和精力的缘故，目前暂时搁置了。


jsvm2 提供额外的语法支持，但这不是强制的，缺省情况下，jsc 还是普通的javascript语法。只有当你通过显式的方式在jsc的文件头部声明为某一种语言时jsvm2的编译器才会去找到相应的语法解析器去做翻译工作。这种设计只是让用户有机会从语法层面上简化一些复杂的编码工作。如果觉得是块鸡肋，可以不必关心这块，就当它不存在，因为它没有给开发带来额外的负担，也没有对系统造成较大的额外负载。（注：jsvm支持多个语法解析器，用户可以通过插件的方式自行扩展或者重新定义）



我觉得目前 _$package() 和 _$import() 在形式上和使用上已经够简单了，如何才算更友好呢？

注：_$package() 也不是强制使用的
例如定义一个包：_$package("com.javaeye");
你也可以不用jsvm自带的_$package()，而直接用下面的方式定义：
if (!window.com)window.com = {};
if (!window.com.javaeye )window.com.javaeye = {};
用_$package 只是可以帮你简化这个过程。


我觉得jsvm的根本目的和基本功能是非常简单的，只是他提供了一些复杂的可扩展的功能，这些功能也是可选的，并不是强制要求使用。但因为文档不足，在某种程度上造成了混淆。另外，我个人不赞成prototype中对 prototype 过多的扩展，这样会对js原生态环境造成破快，jsvm2在这个问题上处理的很小心谨慎，尽量避免这种侵入。

最多只能介绍一下，告诉大家有这么一个东西，感兴趣的人自然会去了解。不感兴趣的人，你说了半天也没用，就比如上面的 iday，我开始说的话，他一句都没看，他自己凭着瞅一眼的直觉说了一些，都没有一个说到点子上，唉！
这个东西某种意义上是被一些精神上的东西驱动地，本身不带商业目的。不过我们会一直做下去，直到被更新的技术或者东西所取代！

支持!虽然我还没有看到源码,但我认为好多开源框架的设计之初都是满足于某一方面的解决,它也反应了设计者本身的设计思路,它在一定程度上给我们的开发带来新的思路.所以我认为我们可以增强交流,让它能够满足大多数人所想解决的问题.

我觉得多一些直接的交流确实是有必要的！作品虽然可以成为思想传递的载体，但毕竟容易被一些形式上的东西和主观意识所误导！况且，国人有种常见的心态：凡是国产的东西，必抱以怀疑的态度去看。我个人觉得虽然这里的同志们在经验和技术水准上都较其他的地方要高一个level，但也要克服浮躁心态，不能一看是国货，只瞅一眼就感觉看穿了别人的心肝脾肺肾，然后下一个专家式的断言。

iday，对不起，我又拿你举例了，反正感觉你好像是无所谓。
俗话说，仁者见仁，淫者见淫，不伦者不能类！浮躁的人不求甚解也就罢了、但自以为是就不好了，我猜，可能连aw和jsvm是个什么东西你都没完全搞清楚，就在这里大放厥词，就抛开aw和jsvm本身不谈，看看你说的那几个问题：

1.  封装过度你的标准是什么？其次，组件的封装和平台本身有太大的关系吗？用简单的object还是用复杂封装方式设计程序，平台对你有限制吗？
2.  “example 中的语法”，那些函数，不是“语法”。
3.  “firefox1.5只有两个例子能跑”，需要先弄清楚不能跑的例子是组件的缘故还是平台的缘故。

另外，jsvm2在windows上的ff1.5上做过测试的。如果在fedora的ff1.5上不能正常工作，你说是firefox还是jsvm要负主要责任呢？

那些小儿之论，实不足与高士共语，请勿复言！或者端正一下态度大家好好交流，如果不敢兴趣，也可以不屑地看一眼，然后走开，不要在这里嘴角一歪，说些胡话。呵呵！

jsvm其实很欢迎大家抱着怀疑的态度去挑毛病，这样才能集聚大家的智慧去完善它，如果一个东西经不起推敲，那说明它本身就是失败的！ 另外，我更希望讨论一件事物，先从主要矛盾开始！

一个简单的调试方式还是很重要的，当然可以体谅作者所说的原因。



我阅读了jsvm的源码，代码写得很精妙，我指的jsc是鸡肋，其实这里jsc指的包括了jsc语法和已经用jsvm语法编写的类。jsc照顾到了java程序员的过渡，但是jsvm核心提供的一些类其实在js中是可以简练的实现的，比如HashMap,StringBuffer等等。而为了支持在前台可以使用这些class，导致需要加载大量的js(比如runtime.js，而且runtime.js里实际是将这些jsc预先解释的，否则效率一定受影响)，所以可能会给人感觉jsvm框架相当重量级。我粗略估计下，对jsc的支持占了所有源码的1/3吧。



jsvm其实实现了一套自己的面向对象的类继承模型，但是没有公开出来，或者说缺乏文档。而在jsvm论坛里提供的插件也大多是简单对已存在的常用js组件的简单封装。就给人感觉jsvm似乎就擅长于集成。吸引开发人员基于 jsvm 来继承的努力显得不太够。



prototype 1.4 以后的版本考虑到了侵入的问题，已经有了改进，比如Object.prototype.extend 就取消了。其他对于 String 和 Array的原型进行扩展，一般情况下除非很特殊的代码，否则不会有什么问题。
也因为prototype 提供了很多让程序员可以得而即用的功能，所以显得很有亲和力。我是希望jsvm也可以提供些有亲和力的工具类，当然最好不是模拟java的形式。

我很尊敬真正潜心开发同时乐于分享的人，也希望jsvm能坚持下去。

说的话听起来不大中听，应该承认中国确实有大量这样的人存在，可能wch3116说的就是我。但是我说的话你有没有仔细想过，其中有没有一点合理性？为了解决你说的两个问题，还有没有更加轻量级的方法？即使我仅仅出于本能排斥模仿Java的开发方式，也不能说完全是我的错，我和你各打20大板是一个比较公正的判决。
其实对于开源软件来说，我跟很多朋友的观点都是无须区分它们的国籍，可以看作是全人类共同的精神财富。Ruby是日本人发明的，我们没有必要因为这个原因就不去使用Ruby。没有必要非给jsvm贴上一个类似于爱国者DC“中国人自己的800w”的标签。你有开发开源软件的自由，别人也有评论的自由，既然你的产品作为开源软件公布出来，就有必要承受别人的品头论足，没有必要像陈大导演一样对一个小小的馒头冲冠一怒。
就目前我在你们的论坛中看到基于这个架构的一些UI组件来说，大多数还相当的初级，无法满足项目开发基本的需求。而类似的组件我已经可以在dojo、prototype/rico等框架中找到，你说我会选择哪一个呢？我既没有兴趣，也没有时间去为jsvm做贡献。按时完成项目，满足用户的需求才是我最关注的。

这里有个产品Dorado，同样是中国人做的，我觉得它做得很不错，对于开发企业应用相当有帮助。可惜它不是开源的，而且据使用过的同志反映，它的设计理念存在着一些问题。如果jsvm想要大力扩充自己的UI组件库，可以参考一下（至少对于要实现哪些组件可以有一个清晰的了解）。
http://www.bstek.com/

Good luck!