我为什么鼓吹thick client

不是对JS没信心，而是你这种用JS的目的和方式值得重新考虑

我的使用方式是通过xmlhttp传递xmldom,前台完全通过js来操作后台servlet返回的xmldom,通过一些已有的js文件或是htc文件动态的生成页面.

js实现这些功能自然是没有问题的,而且我也是这么做的,问题是我现在对于前台大量的依赖js感到忧虑,js毕竟是一种弱类型的脚本语言,它应该是起到辅助作用的,而现在它在我的应用里是起到决定性的作用了,我不得不对它考虑得更深一些,也就因为这样才有这些忧虑,如果仅仅是用个document.write() 我看也就没什么好忧虑了.

这句话我很赞同，这也符合分层的原则。

但我所感到无力的是，js运行在浏览器上，它的性能完全依赖浏览器的性能。现在的IE能够解决很多问题，但也存在很多问题。51JS上甚至还有人发起了一个JSVM，无非是想仿照JVM，想法是不错，但这种私人性质的研究能走多远？



我也是这么认为的，所以才想寻求一种替代品。

对于一些小的项目完全可以限定浏览器的要求，但是在大项目中比较困难，不过这也是一个对js程序员的挑战。

一项技术走多远才算远呢？你没打算你的一套方案要100年后还有人用吧？

一套系统只要我们能做的客户满意、自己做的轻松、收钱容易不就可以了么？

难道你担心一天早上醒来，突然不见了微软的浏览器？
人家Bindows不正做的热火朝天吗？

那就是要准备两手了，JS面向小项目，大项目还是要更严谨的解决方案。



挑战的前提是这种语言给予我能够解决问题的潜力。



这个比喻不恰当，我并不担心JS会突然死亡或是突然冒顶。我只是希望能够通过探讨，从大家那里了解到一些更好，更先进的解决方式，而不是在这里写驳论文。

我不是写驳论文。
既然你已经在JS上花了那么多的功夫，为什么不继续进行下去？没做到底怎么就知道JS无路可走了呢？

如果（假设）用js也可以想Flex那样实现RIA，你愿不愿意试试看？
你都说了有一些关于JS的私人性质的研究，你也欣赏其思想，为什么不加入其中。
其实，如果真的有更好的替代js的东西，不用我们苦苦讨论，市场上自然会出来的，说不定就是你研究出来的私人性质的东西。

实际上，我可以说是js的受害者，我不会刻意维护JS。

看到这里，我倒觉得我们说的JS在界面表现方面应该有两种概念了吧？：
一、平常在HTML页面中使用的js脚本；
二、Laszlo中使用的js脚本；
感觉他们编写方式相同，但运行方式应该还是不同的吧？

弱类型的脚本语言对于我们来说喜忧参半，忧：一不小心就容易出错；喜：容易修改，无需编译。

个人发现公司市场方面人士喜欢用B/S这个名词来欺骗客户，无非就是解决一个自动分发、升级，无需安装。将升级到IE6.0 SP1，安装Flash Play，等等都想作是客户理所应当自己完成的。客户可能也是被B/S这个词蒙了，呵呵
不知大家是否用过招商银行的网上银行，分为大众版和专业版，实现方式就不同，肯定人家也是经过多方面考虑的。

我从自己工作过程总结了三种类型的项目：
1、必须要HTML（看来HTML目前技术还是难以抛弃的），如：网上商城的系统，客户需要通过Google能够搜索到商品信息，如果做成Laszlo或Delphi确实难办；
2、使用Delphi，将客户端做得安装简单，完全可以解决自动升级；其实MSN、QQ男女老少用得真Happy，不知为何setup一下业务系统客户端还是比较反感，不过做做思想工作也就顺利了，呵。这个分发工作还是借助了一个网页，提供下载地址。这个方式可以解决脱机功能，如某现连锁系统，客户端可能需要每天下班之前才联网上送数据的。Java Web Start应该可以看作是在Java语言这方面统一了自动升级的实现标准吧。
3、可以使用Laszlo、Flex这些技术的，相比如上C/S模式感觉也还是过渡模式吧。但不知这种方式是否能够将swf文件作为脱机运行的方式呢（真得试试）？

发现大家有一种寻求：一统天下、一劳永逸的技术方案的想法，不知这是梦想还是幻想？觉得做程序员就得不断学习，其实也不光是程序员！

第一次发言，准备挨批，先去吃饭了，吃饱了再来看，呵呵！！！

weihello 同志其实是为了批判我的观点的，呵呵。
我还是引用 jasonhsu 同志的意见，我们这里应该鼓励各种不同的观点都能提出来，得到充分的讨论，而不是要把观点扼杀在摇篮之中。

我最近特别忙，没有多少时间参与深入的讨论，这里只随便说几句。以前这里讨论基于 JS 的方案已经很充分了，之所以让某些看官认为这里只提倡基于 JS 的方案完全是因为我 dlee 个人的原因。因为我对这个很熟，所以谈得比较多。robbin 和 weihello 说的一些观点基本上也是我现在的想法，所有基于 HTML 的 RIA 方案其实都是过渡的方案。我认为将来的方向是一个基于 XML 来描述的 UI 容器，就是 XAML/XUL/XWT/Thinlet 这类做法。

我非常希望大家都能把自己的经验多谈一些。软件只有有人使用，有人爱用才会有价值，而界面是软件最重要的部分之一。我们谈那么多很高深的设计模式、设计理论，真的不如多花些时间好好研究一下如何把界面和交互做好，让软件对用户更有帮助、更加人性化。不要让用户都认为程序员就是这个世界上最没有人性的一群恐龙。

不过 weihello 有一个误区，就是把 HTML 的命运和 JS 的命运绑在了一起。这个有点像以前我反对的把 CGI 的命运和 Perl 的命运绑在一起一样。其实即使没有多少人写 CGI 了，Perl 仍然有很强大的生命力。WML 使用的 WMLScript 是 JS 的一个变种，XUL、Laszlo、XWT 也使用 JS，我其实是认为 JS 会比 HTML 生命力更强的。至于 HTML 的消亡，我们现在这样说也还有些为时尚早，至少还有两三年吧。我非常不喜欢做预测未来的事情，所以别来问我。这些话都是需要时间来检验的，所以不要说得太死。两年后我和 weihello 再来到这个论坛，看看自己以前做的预测，那是很有意思的事情。

Swing、Java WebStart、Delphi 的开发方式我并不认为会比 JS 简单很多，相反可能会更复杂。根据我们自己的亲身经验，培养一个好的 Java 程序员要比培养一个好的 JS 程序员的时间长的多。XWT、Thinlet 也是用 Applet 实现的，但是它们都是 UI 容器和开发平台，非平台开发人员（应用开发人员）不需要自己开发 Java 程序，这是和 Swing、Java WebStart 这类需要编程的 RIA 方案是有很大差别的。而且 XWT 对于表示逻辑和业务逻辑的分层的严格程度我认为还在 Java WebStart 之上的。

我觉得如果你公司或者你个人在thick或者thin的基础组件积累够用，采用那种
方式都是可行的，我以前一直用Swing做界面，用JavaWebStart发布，自己写了套RPC传输Java对象，由于我们做实时系统实时性要求较高无法采用像HTTP的方式每次请求都开断Socket所以也不能直接引用XMLRPC，界面方面我自己封装了一套布局管理，所以我们写Swing界面从来不用JBuilder或者Eclipse种的插件之类可视化工具，大家也觉得开发效率挺高，好比我问过dlee他说他们开发界面也不用dreamweaver，有了自己的远程调用框架后Swing只是做界面和交互使用后台完全可以采用跟web开发相同的模式。现在我正在参与公司的web项目，我们采用的也是JS＋XMLHTTP方式，刚开始我也有点抵触，老觉得没有thick好用，但是慢慢发现我们公司用XMLHTTP封装的不少好用的组件的确能很大的提高开发效率。

所以我觉得那种方式都有在项目中开发的技术弱点和不足，但是只要基础组件封装好了，可以根据项目的特点随意选择开发模式，好比做综合业务系统用web方式就不错，做电力实时监控系统你只能选择CS方式

不能让用户来挑。
那一种技术都会有一些优缺点，是需要积累的，需要避免trap，所以要采用一种技术，然后对客户需求进行审核和剪裁。