JavaScript version of SWT

http://j2s.sourceforge.net/
我赛......

哇塞~~~~这个要努力的顶。如果全都移植了，那开发起rich client来可要快速多了。再能和dwr buffalo之类的一整和。

坦白说，真的不希望看到更多这样的项目出现。除非是针对特定的项目，而不是挂着 Ajax 或者 web2.0的羊头。

Ajax 不是只有 Javascript， 要编写高效灵活优雅的Web应用，除了JavaScript，对 (x)html、 CSS 以及 DOM 都要有一定的理解(不是了解)。而其后更重要的是对交互的创新思路。

打个比方，你想喝美味的啤酒，如果你认真学习自酿啤酒的方法，学习选择好原料，最终你可以喝到合自己口味的新鲜啤酒。当然也许要多试几次，但从此你都可以喝喜爱的啤酒。

而类似 j2s 这样的项目，提供了一台质量不一定有保证的啤酒机，只能使用指定原料，你先要学习啤酒机的使用，我保证它不会只有一个开关按钮就OK。当然也可以酿造出啤酒，但如果想换换口味，大概就要拆开机子改装了。

学习自酿还是学习使用啤酒机， 很多人都会有答案。美味的啤酒不是一天酿成的。

开发基于java的客户端，工作量显然会大大的小于基于Web的客户端，而且可以获得更复杂的控制。
问题是客户会要求你同时提供javaRCP和WEB界面。如果能够使两者共用同样的代码，难道不是值得高兴的事？

美酒当然值得期待，但是对于实际的应用来说，“把不做的事情最大化”，更值得追求。

没时间试试看，
对一些SWT控件的翻译成js我相信没问题。
可是对控件的事件响应怎么做到呢？

我也是基于这点感到高兴得.并不是非要把这个项目和ajax扯上关系。就是感觉这样子对于表现层的多样化就不是停留在一些框架优点介绍中了。比如写出了某个应用，在公司内网的时候，用SWT客户端，远程办公，用web client。
好比outlook 和 outlook web client.
但是开发起来确是一次的，这岂不美哉

这点我同意。我承认特定的项目中j2s也许是有应用前景的，我指出的是不要挂着 Ajax 或者 web2.0的羊头。

正如你所说 “java的客户端可以获得更复杂的控制”。 但如果想要在web上也获得复杂的控制，很难想像可以用动态生成的js实现出来。因为既然难以动态的生成一个RCP应用出来 ，何以能够动态的生成一个web应用呢。

话不能绝对，如果UI很简单，又没有合适的web开发人员，那么可以试试它。注重实效最好。

我想我该纠正一下。

还是犯了以名臆断的毛病，没认真调查就发表意见。

j2s 其实并非由Java 动态生成 Javascript，而是直接用js 编写了一套基础的jvm(lang,io.util)以及 swt 库。完全同 java 和 swt 的package/class 名字匹配。

和国内一个名为jsvm的项目思路相似，只不过完全遵从jvm和swt的命名规范。

javascript 写成这样，确实不容易。所以它不应该叫Java2Script，而应该是JavaScript2。

对这样的方式，忍不住又想举个例子，犹如一座山挡在路前，上有一条近捷的山路，旁有一条环山的远路，都能到达山对面。你会选择哪条路。

我是愿意上山的，为了可以远眺的风景。

老兄，俺现在正在发愁呢。
客户希望有些功能做成RCP和WEB的两种方式，而我们想最好只实现RCP方式，把View同ApplicationModel先分离，这样WEB和RCP可以共享ApplicationModel部分，如果有软件能够把View翻译成WEB方式，那么我们就不用再开发另外一套View了，岂不美哉。
另外如果交互方式不一样，那么ApplicationModel就复用不了，那么就是完全的另外再开发一套Application层，不爽阿。

有哪位高手仔细研究了一下么？俺也不太清楚它是如何同原来的应用同步状态的。

关于这样的设计我以前发表过一个帖子，
http://forum.iteye.com/viewtopic.php?t=17358
这里的核心在于JS Object Model(API and Semantics) --> Java Model ,这样的设计是很不错，然而不敢想象能够做这样的一一对应，也不敢想象用java代码产生js的代码的性能效率问题，同样，更不敢想象RIA项目需要依赖于一个尚未完善和需要经过验证的设计。