我为什么鼓吹thick client

这个版面好像最流行是XMLHTTP，类似的技术早前也见识过一些。前段日子，moxie对我鼓吹他们的技术（有点类似XMLHTTP）开发如何高效。确实，他的公司开发效率挺高的，至少目前比我们效率高。前提：在前人丰厚的积累基础上。 如果给我足够的积累（人力物力因素），我绝对会比他们快。积累中......
     
  我们先来看看这种js+xml+http的优点：
   1、浏览器，0客户端安装，slim client.
   2、操作系统无关
   3、具有桌面应用程序的一些特征，注意，这里是一些。

  而thickClient的常有的一些问题
   1、安装，升级问题
   2、肥胖问题
   3、操作系统相关问题

  说实话，如果早是几年前我都认为thick Client真没有前途了。当然，现在恰好相反。

  让我们看看thick Client问题的解决方法
    1、安装升级： 我们拥有太多方法了，Java web start就是最好的办法。自动安装升级。

    2、肥胖问题：
       现在芯跳速度越来越让我们对普通的桌面程序效率不再担心；不会再有人给PC配置64兆内存了，因为难以买到；不会有人新配置的机器是window95无盘站或者6.4G硬盘（我的第一台电脑只有6。4G硬盘）。

   3、操作系统？ 嗯？那你一定不会java。

   4、他拥有桌面应用程序所有优点（包括脱机工作），而避免了桌面应用程序最大的几个硬伤，安装/升级/连接限制。我甚至可以建立一个本地数据库。

   5、我们都是java程序员，用接口交流，用代码说话。我和你没有人为的沟壑。想调试任何时候任何人都可以调试。没有人特殊，不存在稀有人才。（这可能就是Robbin所提倡的技术平民化吧）

   6、Client照样可以IoC,可以AOP,可以ORM.

     7、传输方式有N多选择，最差的一种是用XML传输。效率.......

     8、差点忘了说了，不然留下话柄，需要JRE支持。确实，这点总是有点不爽，不过，这个东东好像可以0培训。（当然，还可以从这里骗点钱，卖光盘，不过不要让sun知道）。 如果客户确实要运行业务系统的话，这个代价值得。而且稳定，JS则难说了。

   让我们回头看看js+xml+http:

    1、浏览器相关，据我所知，*****多的实现和浏览器相关。很多都和IE绑定，可是Bill最让人信不过，或需明天为了将firebox挤出，就不知道做了什么。

    2、脱机，本地存储皆是不可能（如果可能就依赖操作系统了吧）。 而这对于一些信息系统来说这太重要了，实际上之前都是特殊问题特殊处理，所以有了p2p之类的。

    3、js程序员+html+java程序员，他们用xml对话。我们知道，甲告诉乙，乙告诉丙，丙告诉丁.......到了戊那儿原话大变样了。再追溯起来就麻烦了。

    4、培养一个Swing的高手代价和培养一个js高手的代价比。写个Swing控件和写个JS组件的代价比。

    5、XML编制/解析，浪费了我的CPU.考验客户的信心。

    6、安全，java总比js这种解释性语言强吧
  
不过，web也有其不可替代位置，对于系统的外部用户，这个thick Client还不是很现实的。



增加名词注解：
   C/S 我不讲了
  
有了b/s结构后，随着应用的深入，浏览器这种request/response的方式比较不爽，刷新过于频繁，界面操作性不强，报表麻烦等等。有人又怀念c/s时代的丰富客户端（rich Client），但又希望拥有B/S（又一说是所谓的三层结构）的优点。
  后来发展出一些新的技术出来，当然，远程调用技术我就不详谈了。这里主要说客户端技术。 rich client客户端技术主要分流为thin client和thick client，只是有时候他们界限并不明显。

  thin client技术的主要以XUL,XAML为代表，也就是利用xml标签描述桌面应用程序的界面，但几乎所有的主要计算工作在服务端（我们叫他应用服务器）完成。这时候，客户端是纤细的，只需要支持XUL或者xaml这两种语言的浏览器。只不过，这界面用起来和c/s程序下的差别不大。 目前上述两种技术都很不完善，还不具备应用开发的大环境。

  thick Client则不同，客户端需要有自己一套程序在跑着，界面逻辑的计算量全部在客户端。就好像c/s程序一样，只是c/s连接的是数据库，thick client连接的是远程应用服务器。这种技术先是开发中用的已经比较多了，只是标准林立。

  类似httpxml这种框架不能分为其中一种类型，他利用了js做了一些rich client工作的技术，他的出现跟rich client本身技术成熟度不够有一定的原因，可以这么说，他是特殊时代的特殊产物。我个人认为，这种技术出生之时，就注定了离消亡不久矣。

  之所以有现在这样的结果，是因为Rich Client标准众多，门派林立，各家由各家的做法，没有形成一定的标准，而且本身又有些技术方面的缺陷或者难题。

  但2005年，第一届Rich client大会将在美国召开，我们期待能有所突破。

我同意。
其实也没有哪个好哪个不好的，我们多了一种选择。最后用什么，应该让用户来挑。

thick client的一个好处是可以大量运用设计模式技巧，
如state

难道那个什么什么TML就不行么？

如果要用模式的话，当然是单一对象语言方便吧。

其实没有绝对的胖瘦 只是相对概念.

如果浏览器支持xul  w3c将uml 作为标准 那么使用xul的也是瘦客户端. 

可以将技术标准看成集合 凡是符合w3c标准 标准浏览器固化的 都是瘦客户端的范围  反之就算胖客户端

最近开始也越发的茫然了，
我想请问一下weihello，你“鼓吹”的和浏览器时代以前的那种thick client加上了java web start是不是一样呢？
受去年第一季度的某本《程序员》唆使，花了我大半年的时间把一个web应用改成了SWT的java web start，效果是很好，但是实在是很费时间。
所以近来转投Laszlo门下，把这应用“翻译”成Laszlo。心想可以大幅度的把中心放在业务本身了，但也有些事与愿违，javascript没有我想象得好写。写得很没信心。

weihello鼓吹的那到底是哪门手艺呢？

从web开发的入门起就是jsp + js，因为感觉到js这种脚本语言在编写web端展现是简单和灵活，所以越发大量的使用js，jsp中的scriplet最后只蜕化成了简单的赋值语句，然后再通过var i = <%=paramter%>交给js去处理。

不过我现在对js的信心是越来越不足了，也许是自己技术不到家的原因，我总是对于js的性能，安全持怀疑态度，处理一些要求不严的东东是没问题，但一旦是一个要求很严格的应用呢？ 也许我写js还只停留在功能级，没有探索的更深一些，但我想，如果这些东西能用java来做，是不是会更好呢？

在web端解决方案中，我手中比较成熟的只有js这么一根“黄瓜”。。暂时还割舍不下，但又极力想寻求一种更好的替代品，唉，矛盾。

解决矛盾的最好办法就是破旧立新，现在的Thick Client技术已经足够用了。
   JS始终不是正道，在我看来，还不如用delphi之类的类似瑞星的升级程序。反正都是基于HTTP+XML.
   用了delphi你甚至还可以有更多的传输方式选则。

我觉得thin client和thick client主要的差别在于以下两点：
1、信息解析的标准是开放的还是封闭的
2、支持开放信息解析标准的部署成本