未来的客户端表现层技术展望

这几天，我先是否定了基于JS+XMLHTTP为核心的浏览器端解决方案，接着又给Javascript的前途判了死刑，搞得一批Javascript/XMLHTTP的死忠份子十分的不爽和反感，其实我一点都不反对Javascript/XMLHTTP，我也一直在寻找比较好的解决方案，当然现阶段，我是不可能找到满意的方案的，否则的话，表示层早就像IoC容器，ORM那样主流观点都统一到一起去了。因为没有满意的方案，所以大家五花八门，所谓八仙过海，各显神通，各有各的绝招，所以呢，如果我不同意你的解决方案，无损于你的形象，大可不必心里郁闷着。

既然现阶段各方案各有利弊，无法统一观点，那我就不谈了，只谈谈未来比较有希望的技术，如果对未来技术发展趋势不感兴趣，对我的清谈不感冒，只对满足客户需求感兴趣的，满意于现阶段解决方案的大可不必往下看了。

众所周之，大家比较看好的未来的表示层客户端技术大概就是XAML和Flex了。但是其实这两种技术我都不懂，XAML还算看了一些MSDN上面的资料，Flex完全就是门外汉了，有人说，你什么都不懂，你还敢大言不惭的预测？ 前面有朋友我说的技术直觉还不错，既然还有人相信我的技术直觉，我就硬着头皮预测预测了。

客户端解决方案能否成为主流，取决于两大因素：

1、技术本身能够真正解决问题并且技术门槛足够底能够迅速普及，这是必要条件
2、这种技术必须得到桌面操作系统和浏览器的充分支持，这是充分条件

要成为主流，必须既满足必要条件，也要满足充分条件，就是充分必要才行。先看看XAML，它满足充分条件，但是能否满足必要条件有待观察，不过从我们对MS公司过去案例的分析来看，他满足必要条件的可能性非常之大。

Flex在充分条件和必要条件两个方面都有待观察，不过Flex可能相比XAML的唯一优势就是Flex支持多种服务器端技术，这比单纯支持MS技术的XAML要更讨反MS阵营的喜好，如果没有IBM/Sun/Oracle/BEA等J2EE阵营的联手支持，Flex就很难成为主流。

所以未来的主流最可能的还就是XAML。那么基于这种预测，来看看J2EE阵营应该怎么应变？XAML通过XML Web Services和服务器端通讯，对于未来的Rich Client来说，业务逻辑不会放在本地，还是在服务器端，所以主要的业务还是在服务器端跑，既然XAML必须走HTTP协议，使用Web Services，那么J2EE来做XAML的服务器端从理论上来说也是完全可行，我甚至已经可以想像到Borland这种骑墙份子肯定会做出来连接两种技术的工具。

但是不会有很多公司做这种费力不讨好的事情，本来可以用一种技术解决问题的，非要人为的用两种技术粘合起来去搞，不是自讨苦吃？相信除了少数特殊情况，例如陈旧系统的改造之类，大部分采用了XAML客户端方案的公司一定会投奔dotnet而去。

MS确实比较狠，从低端的垄断慢慢往高端蚕食，那是不是J2EE必死呢？这却未必。J2EE阵营有三条路可以走：

1、改造J2SE，使之往兼容XAML客户端的路子上面走

谁都知道Java的客户端难用，既然MS已经给J2EE阵营指了条Desktop的路子走，J2EE跟着兼容是肯定没跑的。这样虽然被动些，但是不至于被慢慢抛弃了，不失为上策。

2、封装Swing，提供一个良好的Desktop Application框架

现阶段开发Java桌面应用是比较麻烦的，但是也不是不能做，特别是很多成功的应用证明了用Java做桌面应用程序完全是可行的，如果能够有一套完整的，高效的Desktop Application框架，提高桌面应用程序开发效率，降低桌面应用程序开发门槛，那么J2EE即使在XAML时代，也可以占据一席之地。

现在这方面的框架我知道的有两个：一个是SpringFramework的 Spring Rich Client Project；一个是Eclipse的Rich Client Project。随着未来Linux操作系统在桌面占据一席之地，以及MacOS据守的桌面一角，这种支持跨平台的RCP仍然会成为一种非常好的解决方案。

可以想像使用RCP做桌面应用程序，处理和用户的交互，然后通过Hessian/Burlap/SOAP和服务器端业务逻辑通讯，这种方式完全可以对抗XAML。这是中策。

3、J2EE阵营联合起来力推Flex，共同对抗XAML

J2EE阵营能否联合起来这只是一个美丽的幻想，因此是下策


其实说了那么多，最后说说我对当前这么多客户端解决方案的倾向性问题：

1、HTML为主，Javascript为辅

这种方式是大部分人采用的，也是我默认的方案

2、XMLHTTP为核心，Javascript驱动

这种方式少部分有技术积累的公司采用，但是我认为不具备大规模推广使用的可能

3、Activex

ActiveX往往也是方式1的辅助手段，也少碰到主要靠ActiveX驱动的，我只见国一个叫做“线线通”的在线游戏网站采用

4、Applet

这种方式往往被大公司广泛采用。如果有RCP的良好支持，我认为可以做为方式1的良好辅助

5、Flash

完全用Flash这种方式来驱动网站的我到见过不少，Javalobby也有一部分这样搞的，其实flash本质上也就是一个ActiveX，这种方式能否流行关键还是看能否得到广泛的支持

综上所述，我是会坚持采用方式1，即HTML为主，Javascript为辅的方式，并且会尝试在业务逻辑复杂的地方使用Applet/Flash来解决问题。

考虑到未来的可能性，其实我个人还是十分看好Spring的RCP项目的，也希望RCP项目的成功，通过Java Web Start来发布项目，使用RCP有效降低Desktop Application的开发成本，利用SpringFramework统一的解决方案，未始不会创造出来J2EE的一片新天地。

其实管他什么技术，关键是解决问题的能力和方法。
我是不会抱着几样东西不放的，只是当前的侧重点不同而已，相信大家也是。

卡卡，经典的废话。看我造句：

其实管他从事什么行业，关键是赚钱的能力和方法。
我不是会抱着编程不放的，只是当前的侧重点不同而已，相信大家也是。

:) 偶没有不爽更没有反感，只是说了点自己做的心得罢了。阿拉更不是什么Javascript/XMLHTTP的死忠份子，上面让做了，俺能说什么呢？不像你们系统的框架你们说了算 ，其实我是十分看好Flash的，可是那又怎么样呢？还要搞我的js，还要想那个浏览器为什么要崩溃...

asp.net webcontrol难道不是一种选择吗？老实说，现在的asp.net 的控件提供商已经相当成熟
随便列一些站点
http://www.janusys.com/controls/
http://www.telerik.com/
http://www.componentone.com/
http://www.infragistics.com/

还有许许多多的控件提供商，不一一列举了

除去webcontrol viewstate的笨重外，其实webcontrol是很好的封装，利用了js,但程序员却不必深入了解js

呵呵，是啊，
不过，什么话都是有目的性的啊，我只是看你们有点针对，打个圆场，缓和下气氛嘛。

我都强调了n(n>8 )次了，我不反对Javascript/XMLHTTP，我很支持大家去搞XMLHTTP的框架，只不过我自己不看好这种技术而已，我自己不支持可不等于我反对。我之所以另外开帖子讨论，也不是想反驳谁，我只是想讨论一下XAML的前途，和J2EE表示层将来怎么发展的问题，而Javascript/XMLHTTP不在这个帖子的讨论范畴内。

对啊，我早就这样认为乐，不过，之所以还想发言，是因为我觉得，你的话实在是有道理的。

说白乐，我只是支持一下U罢乐，我以为只是“支持”2字，显得我瞎说，那就说说自己的想法嘛，至于让别人理解成经典废话，实在非我所愿。
想起葛优在不见不散中的那段他叫小朋友中国式的问好。

robbin 辛苦了，，要这样讲还不如讲RIA( Rich Internet Applications)

忘记了最成熟的一块，XUL
Demo


XUL：XUL（念作"zool"）是一个基于XML的用户界面语言，它来自于Mozilla的开放源码项目。它可用于建立窗体应用程序，这些应用程序不但可以在Mozilla浏览器上运行，而且也可以运行在其他描述引擎上，如Zulu（一个Flash MX组件）和Thinleys（一个Java实现）。XUL描述引擎都非常小（100K以下），它可以使用XML数据也可以生成XML数据。