讨论：Rich Client为什么不选择Applet或Web Start ?

大家讨论了这么多Rich Client的技术，不论是Tapestry, Struts, WebWork还是其他，都是基于Html+script(javascript等)的解决方案。要用script完成和应用程序一样强大的功能（在我看来大多数web应用都没能力和应用程序比），需要耗费我们成倍的精力。也许还存在很多问题（例如安全性）。我相信，现在的基于Html+Script的技术决不会是未来主流的Rich Client的解决方案，除非开发方式和技术有本质的改变。

我们由传统的C/S架构转移到B/S架构，最主要的原动力是什么？（访问）方便，易维护，这或许不是全部的原因，但绝对是至关重要的因素之一。但为此，我们牺牲的传统应用程序强大的展示功能，牺牲了开发的效率。

再谈瘦客户的问题：时间长了，很多人就慢慢认为只有使用浏览器的模式才能称为瘦客户。可是大家别忘了，不论是windows上的IE还是linux上的Mozila都是预装的。假如每个操作系统上都预装了最新版本的java虚拟机，或是用户很容易就能获取到最新版本的虚拟机，你还会认为运行applet要装客户端吗？

我个人觉得applet和web start技术或许不是最好的解决方案，但和我们现在广泛采用的技术相比，还是有着很大的优势。它兼顾了C/S和B/S的优势。利用web start技术，我们可以在客户端缓存应用程序，并且一样能享受自动更新的好处。我们可以采用传统的rmi等方式访问服务，或利用web service整合应用。我们的部分应用甚至能够在离线的状态下使用。

可是一项技术流行与否总有它自己的原因，我对此一直感到比较疑惑。

我支持Applet，我认为它是个好技术，只不过微软和SUN之间的都斗争毁了这个很有前途的大规模应用，反倒是被Macromedia的Flash后来居上了。
    
      其实Applet的应用要看项目的范围。如果是面向普通大众的Web页面，那么使用Applet有一定的风险。在这方面Applet存在着一些不好预知的陷阱。回顾一下历史，就会发现这并不是Applet技术本身不好：
     
     Applet被提出一段时间之后，国外基于Applet的网站出现了不少。就拿微软自己的MSDN网站，最初（1997-1999之间，可能时间不是太准确）都是用VJ建立的基于Applet的网站。为什么会这样？很简单，就是Applet有其他技术不可简单比拟的优点：局部刷新，界面类似于Windows上的普通程序，易于用户使用。从编程者的角度来看，不用掌握太多的技术，只要懂Java，就可以开发出基于Web的应用程序。Java在诞生的时候为什么被称为互联网上的世界语？这个世界语怎么得来的？就是Java可以在互联网上运行。怎么运行呢？不就是Applet吗？所以，当初Java出现时SUN是主推Applet的。而微软也拿Java作为自己的底层应用。可以看看Windows95到98的转变，就是内嵌了Java的虚拟机技术。微软的IE、SQLServer7.0,各种开发工具，都以Java虚拟机为基础。前些阵子微软宣布不再支持98、NT4、SQLServer7，不就是说这些系统的JAVA虚拟机不受支持了吗？其实微软早就看出虚拟机可以屏蔽底层架构，加强系统的可靠性的优点，而系统的可靠性又是微软挺进高端企业级应用的最大障碍，Java恰恰可以解决这个问题，所以微软当时应该很看好Java的这种重构系统的作用，所以也不遗余力地研发自己的Java。但SUN害怕微软的影响力，从自己的手里夺走对Java的控制权，就也找寻各种借口，想尽各种方法不让微软取得Java的实际控制权。比如SUN不给微软新版Java技术的授权，只让微软用老的Java技术等等。因此，如果我们用IE作为Applet运行平台，只能使用JDK1.1中的技术，而不能使用JDK1.2以后的技术。这表面上看似SUN占了上风，实则钳制了Java的发展，没了Windows内置的支持，你的跨平台还有多少市场？Applet因此也成了两家公司斗争的牺牲品，本来有着大好前途的应用得不到更大的发展。当SUN意识到了这一点，为时以晚，微软已经有了DOTNET虚拟机了，可以抛开Java了。以前是微软找不到可以代替Java的虚拟机技术，所以只好支持Java，而现在，微软有了和SUN叫板的资本，所以就宣称Windows不再支持Java了，98、2000里面内嵌的虚拟机也从XP、2003里去掉到了。这样，对Applet应用更为不利了。所以，我们看到现在的Java都成了服务器端编程的工具了，那客户端呢？Java当初赖以成名的世界语形象上哪去了？我们应该承认这是一种Java发展的倒退，罪魁祸首表面上看是微软，实际上应该是SUN对Java的垄断的一颗私心。

      其实微软在Java上是花了不少力气的，据一份资料上讲，微软在推出VJ6之前，曾有公司对其内部测试版生成的Windows程序的执行效率和其他编程语言产生的Windows程序进行了对比测试，结果吃惊的发现VJ产生的代码的效率竟然超过了C++代码产生的Windows程序的执行效率。可以想见，如果微软和SUN能同力合作，这么多年了，Java的执行效率就真的不能提高？我们现在不用Applet的理由之一：加载和执行速度缓慢根本就不应该是问题，平台不支持就更不应是问题。微软在桌面系统的速度和优化方面的功力是无出其右的，因为她拥有创建了Turbo Pascal的天才 Anders Hejlsberg，他对编译器的优化功力世所罕见。凡用过Turbo Pascal和Delphi的都会惊诧于这种编译器的闪电般的编译速度和执行速度，而这些都是拜 Anders Hejlsberg所赐，刚才提到的VJ也是出自他的手中。所以，两家能相互谅解，共促Java的发展，真应该是IT界的一大幸事，Java也真的能够实现它的世界语的理想，而这个理想国就是Applet的世界。可惜天下总是没有那么好的事情啊。

    平心而论，作为Web表示层的Rich客户端技术，Applet确实具有得天独厚的优势。就拿这个论坛讨论的动态HTML、XMLHttp协议实现的局部刷新的网页技术等等，哪个不需要你同时学习并精通HTML、JavaScript、CSS、XML、DHTML，DOM，浏览器事件模型，再加上不同浏览器之间的差异，真是让人看着就头痛，不好好花段时间学习是掌握不了的。就算掌握了，用起来真的就是那么简单吗？再说这些界面的速度和对运行客户机的性能需求，也不见得就比Applet要强多少，有时候甚至还不如Applet。再有，这些客户端脚本代码是暴露给最终用户的，不利于自己公司的技术保密。而Applet呢？只需要掌握Java语言本身，懂一点点HTML基础知识就可以了，而本身又是编译好的字节码，至少在界面上不容意被破解。XMLHttp所谓的局部刷新更是与生俱来，不用费老鼻子劲用成百上千行的JavaScript代码在IE里堆砌那些Windows程序中常见树啊、选项卡、数据表等控件了。从这几个角度出发，我建议Web表示层技术区真应该吸纳更多的‘关于Applet的技术心得。本身这个论坛就是主要是讨论的Java技术，那些XML、JavaScript、DHTML毕竟还是不属于Java语言本身的东西。

      我们针对一个企业提出自己的项目方案，可以肯定的是企业内部环境是可以控制的。而Applet对浏览器的适用性并不输于JavaScript，有的时候往往还优于JavaScript。所以，我建议应该把Applet作为一个实用的项目技术加以考虑。至少在基于Java的项目中，Applet应是可控环境中Rich客户端的首选。

      在互联网上，Applet也不是没有比较成功案例。大家都玩过网络游戏，一般都要下客户端，比如联众的客户端，第一次用起来又下载又安装很麻烦。而263的网络游戏就是基于Applet的，他用的就是Windows内置的Java虚拟机，所以不需要单独安装SUN的jre，用户玩的时候根本就不用下客户端，非常方便，运行速度也不错。由此可见，Applet还是很好的。我认为钻研如何在JDK1.1中实现更漂亮的树、选项卡、特型按钮比钻研用JavaScript实现局部刷新、实现同样的树、选项卡、特性按钮要容易的多，也有趣的多，至少是把精力放在了应该放的Java上。

从楼上的发言可以看出，很多人认为IE对Applet支持的不好，运行Applet要下载额外的JVM。其实这是一种误解，IE对Applet支持相当好，比Mozillla和Netscape要好的多。
     IE中使用Applet是否要下载额外的JVM，就要看你的Applet是基于JDK1.1还是JDK1.2以上版本。如果Applet基于JDK1.1，那么IE就根本不需要下载什么插件，因为Window98、Windows NT4.0、Windows2000、都已经内置了微软的Java虚拟机了。只有WindowsXP和Windows2003需要下载VM。但现在好多OEM版的XP和2003也已经内置了Java虚拟机（就是那些随品牌机预装的WindowsXP或2003），所以这些用户也不用去单独下载VM。
    如果你用JDK1.2以上来开发Applet，那这个Applet要正常执行就要用户下载SUN的Java虚拟机了。所以，我建议如果用Applet，最好基于JDK1.1，这样使用IE时就不会不会让用户额外再下载Java虚拟机。在是否需要下载虚拟机这个问题上，IE是比较好的，基本上基于JDK1.1的Applet都可以无需做任何设置就可在IE里快速正常的执行。比较麻烦的反倒是那些使用诸如Mozilla浏览器的用户，他们必须预先安装SUN的Java虚拟机，这些浏览器不能使用Windows内值的Java虚拟机

你提的问题其实也是我很想和大家讨论的问题，请参见我前面发的帖子对所谓“下一代B/S技术”的思考，欢迎讨论，以我自己的开发经验，我做过applet(包括swing和SWT)，PHP、JSP，有几年没有再研究WEB技术了，最近一看，那么多框架技术，什么tapestry, struts, webwork等等，都是基于HTML模式的B/S框架，赶忙找资料学了学，都是好东东啊，但前提是你要开发HTML模式的B/S才会用到这些框架技术，我注意到有网友在讨论javascript+xmlhttp模式的开发方式，也很疑惑为什么不用APPLET，还看到FLEX如此有前途，那么研究前面提到的那些WEB框架还有什么意义呢？
我觉得我们首先要回答为什么需要rich client，然后再讨论rich client选择什么的问题。rich client的优点在于操作方便快捷而且有本地数据保存的特性，缺点在于初始下载量大，但是这个缺点现在看来随着带宽的增加已经不是什么问题了，但是我认为它还有两个更重要的缺点，一是信息的展现能力不如HTML，二是如果你做rich client就意味着必须定义前后台的通讯接口，不如HTML这种通用的接口来得方便。
如果你仅仅做交互式应用不需要花哨的信息呈现，那完全可以用applet这样的rich client（当然需要定义通讯接口的缺点还是存在的），但如果需要同时做漂亮的信息呈现和交互应用那就必须得用HTML，但也许人们也期望同时保留rich client的优点（如部分刷新），所以给了javascritp+xmlhttp这样的rich client模式的生存空间，但我个人觉得这种开发比纯的applet麻烦很多。
不过我还在思考一个问题，到底是纯的交互应用多呢还是表现与交互混杂的应用多？我们可以举下例，想网上购物、政府网站这样的项目都属于混合型，而象企业MIS、ERP等应该都属于纯交互型，如果做前者的话我们学WEB框架还可以派上用场，如果做后者的项目我觉得完全可以用applet搞定，还有用WEB框架的必要吗？

看了楼上的帖子，都是一片为Applet呐喊的支持声，
谁说Applet不被看好，至少有这么多人在支持么。

不过不能不说现在看不到什么用Applet做的RIA Client
在流行方面，它确实不如其他那些技术那么普遍。
我本人也不喜欢Applet，原因有以下几点：

1. Applet 做出来的界面太难看了。（这不是Applet的错，是Sun的错，Java写出来的界面实在是不好看。）

2. Applet 还是需要特别安装一个plugin来支持，如hdwangyi说的，用1.1开发的Applet有很好的兼容性，可问题是你能不能把界面局限在只用1.1的API上。AWT在1.1和1.2上是有着本质的区别的，另外如果使用Swing呢？只用1.1能不能解决问题？如果只是简单的几个Text Box，那么用Applet干吗呢？

3. Applet 一向是被专制的对象，就因为它应用Java，具有空前强大的能力，所以可能造成的危害就格外大，本地文件访问功能几乎是被禁止的，很多人出于安全考虑甚至禁止了Java Applet的使用。这样的应用不具有广泛的适应性。

4. Applet 在现阶段仍然有初始化慢，启动慢，运行慢的缺点，不管是不是因为网络或者Java本身造成的原因，总之给人的感觉不很亲切。我再使用中觉得Applet程序运行的并不稳定，经常崩溃，甚至拖垮浏览器。（不知道是不是插件作的不好）

Applet之所以在产生的初期非常流行，是因为那个时候没有替代的技术，试想那个年代，Java Script只停留在在网页上算个数之类的水准，XML还只是它各种标签语言前身，而Flash则干脆还没有产生，Applet的出现足以让人惊叹，它解决了很多当时无法实现的问题，毫无疑问成了人们的宠儿，而随着时代的变迁，新的技术的出现，人们的选择也会改变。打个比方Java就像Main Frame 一样功能强大而昂贵，一般的用户买不起，也不可能完全发挥它的效用，Applet就像一个Main Frame的终端，在没有微型计算机的时代，大家都争取要一个终端，来完成自己的工作。可是现在微机已经强大到能够解决人们日常所有的问题了，那么大多数人都会买台微机而不再去使用价格昂贵，而又使用不便的终端了。Main Frame依然在他该工作的场合发挥着作用，只是大家与他连接的方式改变了而已。

当然，象一个内嵌于浏览器的Telnet终端这样的应用，用Applet似乎是非常合理的。因为它对界面的要求上，对内部处理，网络通讯的要求多。（看，又回到终端的问题上来了吧！）

总之，如果加以改进，Applet是可能在未来的客户端市场里占有一席之地的，但在五彩缤纷的RIA风行的年代，我并不看好它。

Applet 有一些问题，不过不是很大。主要是调试起来不太方便（至少不如 JS 方便），代码修改后比 JS 多了一步重新编译的过程。IE 的老版本（4.0）有些问题，有时候会出现 Applet 在服务器明明更新过了，刷新页面后还是用的老的 Applet 的情况。新版本我不太清楚。IE6 已经不支持 Applet 了，要另外安装插件。
以前我对 SVG 寄予厚望，但是 SVG 一直没成气候，主要是因为开发量大，不太方便。Flex 出来后，用 Applet 的可能会更少了。不过在适当场合用 Applet 也没什么问题。一些围棋站点用 Applet 做的功能是很不错的。

flash为什么这么流行， 大家自己写几个applet看看就知道了。

现在有很多js的控件，用起来也挺方便，楼上说的对，有些应用Applet是可以，Applet没有发展起来是商业竞争导致了他的没落。所以从目前来说还是js+html+css加上合理的框架才是主流。不过对于应用程序来说，如果你设计合理，以后有了新的技术，你的应用逻辑还是可以不变的。把UI变化一下就是了！

biz应用,applet其实是非常好的选择.
至少从developer的角度来看就是不错.

withwind写道：

Java做的界面并不难看，说Java界面难看的是因为你没见过做的好的例子。


用JDK1.1同样可以开发出树、表（可以显示普通文本、图片，类似于JDK1.3以上版本提供的JFC演示SwingSet中的那个列表）、选项卡、类似OutLook选项卡等较为复杂的界面控件，而且速度、效率都不输于Swing，推荐大家看一下《Java图形用户界面设计》（电子工业出版社），这本书提供了利用JDK1.1做出的各种精彩的控件，而且有源码，非常实用。其实，如果你用过VJ6，就会发现微软为JDK1.1已经提供了足够多的控件，只要你不介意跨平台，只要是IE就可以用这些控件，这些控件称为AFC，可以直接通过Visual J++来使用他们，这些控件可以在IE中直接使用而无需安装SUN的JRE插件


     基于浏览器的其它技术就可以直接访问本地文件吗？用户就不能禁止JScript脚本吗？你用的DHTML就具有广泛的适用性？ 一套代码就可以保证任何浏览器都支持？恐怕未必吧？


    用Windows自身的JVM很少崩溃，拖垮浏览器很少见，倒是大量的JavaScript脚本经常拖垮浏览器，尤其是IE。脚本用多了，在Internet上的时候经常不能下载完全，造成执行错误，不信问问周围的人在访问Sina、Sohu时是不是经常发生脚本执行错误？再有，当脚本没有完全下载时，用户按“刷新”按钮时由DHTML构建的当前的界面会消失，回到原始的不含DHTML生成的界面，这些问题解决起来很复杂，难道这种大规模使用脚本的技术就具有广泛的适用行吗？另外，JavaScipt执行起来就比Applet快？毕竟JavaScript是由浏览器解释执行的，而Applet缺是编译好的类文件，由Java虚拟机直接执行的，两者的效率谁高谁低还看不出来？说Applet加载慢？同样的功能（复杂到一定程度），你看看JavaScript要加载多长时间？去看看那个bindows的功能演示吧，那个用JavaScript脚本对机器的要求有多高？速度有多慢？在访问一下这个版的那个“XmlHttp实现的输入拼音首字母选择的例子”的网站，看看会出现多少个脚本运行错误？我的机器刚刚打完IE的补丁，一个劲的报“禁止访问”的错误！我觉得，在互联网上大规模的用脚本的时代还没来到，也许永远不会来到（微软又出新技术了！Longhorn在Web方面又有新进展了！IE的开发已经被停止了 ）


dlee写到： 

谁说IE6不支持Applet？我一直都再用IE6，也没有额外装JRE插件，
却经常用263的Applet玩象棋，这怎么解释？其实不是IE6不支持
Applet，而是在Windows XP和Windows2003里面没有内置JVM，这和
IE无关。你在Windows2000和Windows98中完全可以不用下插件在IE6里
用Applet（当然这种Applet必须是基于AWT1.1的编写的），至少我没有
碰到Applet崩溃

captain写到：

   flash目前只适用于一些简单的演示和广告，比起Applet更少
在项目解决方案中应用。从善于表达复杂的逻辑这一特点上来看，
Flash还有很长的路要走。我看过一本书，介绍完全用Flash完成
动态网站的开发，需要先写ASP或JSP,再利用Flash调用这些动态页面，
天，好复杂啊！