关于 jsvm 的争论

在CSDN的JavaScript版有过讨论：
http://community.csdn.net/Expert/TopicView3.asp?id=4506486

J2S更多注重的是复用已有的Java代码，这个或许与JSVM有点不同。

J2S不是重新去实现那些代码已经实现的功能（甚至不拷贝修改源代码），而只是重新编译。而J2S提供的编译器，这一点更像是一套语言了。虽然这只是一种语言到另外一种语言的转换。

我的理解：
Java2Script是Java to JavaScript，而JSVM是JavaScript for Java。一个是2，一个是4。

这两者的本质（或者说出发点）我觉得有点不一样。JSVM是自己实现了一套运行的环境，包括很多API函数。而J2S更多的是提供一个底层的*.js文件，然后其它的代码都是由已有的Java代码来生成（有可能需要稍微做点小改动），也就是说Java2Script更多地站在Java开发者而不是 JavaScript开发者的角度来发展的。

当然如果就虚拟机的层次来说，其实两者是相似的。

而真正地站在Eclipse JDT这个巨人的肩膀上，我觉得这个是J2S的最大亮点。

但是就复用的效率而言，就如前面有人说的，J2S的命名更加规范化，也就是能够更好地复用已有的code（更重要的是复用已有的工具，例如J2S tutorial使用到的Visual Editor一样）。

jsvm 的目的不是他本身提供一套丰富的js类库或UI组件给大家用，而是帮助你管理维护部署这些代码！Map 和 List 的用处，你们目前看不到，那可能是因为js在你目前的应用开发中比重不是很大！（个人猜测）


也许组件的效果是一样的，但开发的工作量是有差别的！


我的兴趣很广泛！我对jsvm的定位不代表我本人的兴趣爱好只专注于这一块！


你这里说的和我的意思不是一回事！


呵呵，自然别人也绝不会这么干！关于这一块jsvm是如何考虑的我后面会介绍！

jsvm 并不是“为了实现js的模块化而实现一种新的前台语法”，“模块化”和“额外语法”在这里是毫无关系的。
jsvm2 中缺省自带了一套面向对象的继承模型，但是jsvm并没有强制要求开发人员必须按照这个模型来设计js class，但是如果你想利用这个模型来实现面向对象的js设计，那么启用jsvm2自带的额外语法可以帮助你简化这个过程！

通过后台动态生成js，我个人不赞成这种方式，前后台的应该是一种松散耦合的关系，他们可以完全横向切分开

我个人并不把jsvm和j2s作为同一类产品，至于它和java的关系，很简单，就是：没有关系！绝不是 javascript to java 或 javascript for java。若认为jsvm在形式上也有点类似java，那只能说他们两者在解决某一些问题上（例如代码组织）采用了类似的思路。而那些类似的api命名，也只是名称而已，用import还是用using，其实无所谓的！

问几个问题：
相对于已经存在并普遍流行的prototype/dojo/altas等框架，JSVM的特点（或优势）是什么？
另外一个学习成本的问题：如果别人要用JSVM的话，则是否需要额外学习一套类似Java却不完成相同或者是Java和JavaScript混杂语法？同时由于这套语法还没有强壮的IDE支持，是否编写相关代码不会带来效率的提高，对“程序员”是否尚不友好？

JSVM 更加专注于js模块化设计的底层服务，功能完备且有伸缩性。
提供了一套较为完整“有状态的富客户端”的概念和解决方案。
自我封闭无侵入，对web上的js原生环境几乎没有破坏，可以和别的js framework共存，对上层应用开发没有过多的约束，程序员有非常大的自由度。

jsvm2 是一个高度弹性的框架，其中基本功能非常简单，不需要学习额外语法。
这里有些成熟的组件移植到jsvm2上的例子，http://jsvm.org/demo ，通过这些例子我们可以看到，如果基于jsvm2开发这些组件也同样很简单，而且代码的维护和部署将更加方便！

我一直觉得：分析一个事物最好在全面了解他之后。如果仅是从某几个角度去看，就容易犯类似犯盲人摸象的错误！
纵观整个软件架构的发展过程，其实和现实社会的发展模式是差不多的。

新的事物诞生初期会以各种形态出现。经过一段时间的优胜劣汰，自然选择，最终会稳定下来向一个统一标准靠拢！（一般来说是最优的一种形态）而这部分将沉积下来成为社会下一步发展的基础！
就目前业界的发展来看，NGN，软交换，都已经标示着通讯行业正在向IT行业整合，所有的硬件平台和网络协议都在向一个统一的标准靠拢！(现实中人类的语言和产业也在整合)
当硬件平台统一之后，整个IT业就只剩下软件了。而软件这一块的发展也类似，虽然目前有多种OS纷争市场，但是我们可以看到：有着统一标准的浏览器已经在屏蔽不同操作系统之间的差异。
继续发展下去，下一代“浏览器”其实就取代了如今OS的地位。也就是说软件也将形成一个更高层次的统一平台。那个时候多种OS已经没有意义，只会剩下一种os 并直接集成到硬件中，类似现在的BIOS。

在一个统一的平台初步形成之后，整个 IT 产业的重心会转到按照业务来划分系统，SOA，面向服务的架构，也就随之出现了。
我这里不是要和大家讨论SOA，而是要说SOA架构的系统的一个特征：无状态性

服务端无状态的优势和必要性,我想大家都应该清楚，这里就不讨论了。
既然服务端被设计成无状态，那么会话状态无疑主要由客户端来保存。

所以我以为，一个真正的ajax富客户端应用，应当是一个有状态的客户端。
以前相互独立的page必须通过某种机制集成在一起，成为一个有机的整体。
page之间的通讯也都将直接在客户端完成。

jsvm 为page设计了4种运行模式，standlone,application,module,auto ，
因为 application 和 module 不能独立存在,他们必须结合使用。所以其实就是两种运行模式：
独立模式(standlone) 和 应用程序模式 (application + module)

独立模式很简单，就是传统的页面方式。而应用程序模式就是为了实现上面说的一个有状态的富客户端而设计的。
我预测，以后的ajax的应用将主要是这种模式。

因此我对这一类的应用开发，规划分几个层次（步骤），
jsvm 是其中的第一步。
实用类库 和 UI 组件库和是第二步。
大规模的富客户端应用开发是第三步。

我把ajax应用开发的工作分成了这几个层面，层与层之间的边界是非常清楚的。
所以 dlee 和其他同志以为我不够重视UI组件的开发，其实是一种误解！
我只是觉得在我重点投入开发UI组件和更多实用的类库之前，我应该做好第一步:搭建好一个足够灵活且强壮的平台，为我以后的开发提供良好的底层的支撑！

关于jsvm中应用程序模式的使用，这里有一个简单的例子 http://jsvm.org/demo/

(未完待续...)

我基本上理解了万常华同志的想法。讨论Ajax基础架构的设计确实非常有帮助，有些不同意见我们还可以深入探讨。

如果建造UI组件的话，我有几个建议。
1. 首先，Web标准这些年取得了很大的发展。建造UI组件一定要基于真正的Web标准，这样才能跨浏览器和达到高度的可用性。至少对于IE、 Firefox、Opera 3大主流浏览器（可能还有Safri）都要有很好的支持。Google、Yahoo!等大公司对此都非常重视，国内的大型门户网站例如网易、新浪也已经重视了起来。实现这个目标并不像某些人想象的那样是火箭科技，关键还是要掌握诀窍。

2. 其次，虽然XHTML1.0，甚至是HTML4.0都早已强烈推荐基于CSS做布局的方法，然而现在国内大部分页面制作人员仍然顽固地坚持差不多10年前的基于table的布局方法。一个完全基于table做布局的Tree组件或者Grid组件，开发维护起来都要比基于CSS做布局的组件更加复杂，因此不能被认为是先进的。

3. 第三，实现UI组件，要注意将页面中structure、presentation、behaviour 3部分的分离，将这3部分分离开，这样的组件才便于维护和修改，同时良好的功能划分也为以后在客户端引入MVC架构提供了非常好的基础。
这3部分的分离一般是通过独立的html、css、js文件来实现的。

4. 第四，建造UI组件，不是一个单纯的技术工作。除了要充分理解Web标准，以及具有大量的编程知识之外，还需要设计者对于交互设计有着深入的理解。这样才能设计出可用性很好的UI组件。美国在Web可用性这个领域有非常深入的研究，并且对于一些公共机构网站的可用性还有相关的法律条款。

关于CSS设计，我推荐著名的CSS Zen Garden网站的负责人写的一本书：
The Zen of CSS Design，这本书已经可以在eMule等工具上找到。

从demo看像"中间件"的概念


其实JSVM的API使用已经额外的学习成本了。当然无论是Yahoo UI库还是Prototype+Scriptutous，还是Bindowns或者DOJO还是Backbase，其实都有新的API的学习成本。

后面的第二步第三步的开发感觉JSVM的底气不足，因为“实用”要求新设计的API需要完备，这需要一个很长的时间，而“大规模”的开发需要强有力的工具支持，如果这个工具是新开发的，则工具的开发和成熟是按年数来统计的。

当然我个人是倾向Java2Script的方式的。大部分的开发都是基于Java的，对众多的Java程序员来说都是熟悉的API，而且开发环境也是熟悉的Eclipse JDT开发环境。
同时在UI库的“实用”上，J2S选择的是SWT API，由于SWT的成熟，和相关界面设计工具的成熟，也使得UI库不是一个设计是否完备的问题，只存在性能优化的问题。
而“大规模”开发，本来Eclipse的JDT开发环境就已经具备了大规模开发的支持了。
当然J2S还不成熟，也可能存在瓶颈，但是毕竟这个方向问题，感觉J2S是对的。

当然Java2Script的开发不是中间件的方式，是从最底层开始的。即使是从最底层开始，但是毕竟Java的API对于大量的Java程序员来说都是最熟悉不过了。而且只要求Java程序员知道基本的JavaScript知识（甚至不需要知道）。而且开发和组织代码结构都是直接使用Java来开发的，可谓让程序员非常熟悉。

毕竟尽量地“复用已有的代码、API、工具”也是基于JavaScript的web applications的一个关键问题，当然也是J2S的优势。而对此，如果JSVM是一种“中间件”平台，这是在复用；但是在复用程度（譬如那些js.util.ArrayList/HashMap/Stack，js.lang.*），我对JSVM还抱怀疑态度。

我个人同意dlee对UI组件开发的四点建议,（当然，我也同意胡总书记对台湾问题的四点建议）
目前为止，jsvm2上能看到的UI组件多数都是从现有的成熟产品中迁移过去的（例如：yahoo userinterface library, activewedgets 等..）。
大家还没有看到jsvm团队自己开发的UI组件。

一方面是为了说明jsvm的兼容性和之上的开发自由程度。另外，还有一个主要原因是：

我觉得除上面的四点建议之外，在大规模开发UI组件之前还必须做两件事：

1。制定一个 JS Object 和 HTML Element 映射规则。我知道，UI组件的最终实体还是HTML，如何制定一个简单易用的关联规则，目的是让 js object很容易访问到对应的 html element，同时 html element 很容易反过来回调 js object。建立这个统一的规则以后，我们就可以很容易建立一个js 和 html 数据同步绑定的机制。
2。确定一个事件模型，目前我倾向于采用 w3c dom level 2 的标准。

这个模型中有3个核心对象：

org.w3c.dom.events.Event;
org.w3c.dom.events.EventTarget;
org.w3c.dom.events.EventListener;

这个大家都熟悉，也是web标准之一，我就不多说了。

当然一些简单的UI组件也不一定非要遵循上面这些标准。（这一点不作强制要求）

(未完待续...)