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

Web客户端未来的发展趋势是XAML这种界面描述语言和事件响应机制代码的时代，我仍然最看好XAML，其次是Flex/laszlo，但是不太看好XUL，我觉得XUL缺乏一个从客户端到服务器端的整体解决方案。

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

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


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

在当前阶段，我比较倾向于如下的方案：

如果是做Web项目，例如开发企业应用软件系统，我会比较倾向于使用Applet/JWS来处理无法用HTML/JS完成的负责的用户交互处理过程

如果是做website，例如做网站，我会倾向于使用Flex/laszlo。

Web客户端未来的发展趋势是XAML这种界面描述语言和事件响应机制代码的时代，我仍然最看好XAML，其次是Flex/laszlo，但是不太看好XUL，我觉得XUL缺乏一个从客户端到服务器端的整体解决方案。

关于目前如火如荼的JSF，我很高兴看到这个功能强大的开发框架的出现。
但说实话，我不认为，TagLib可视化拖放开发足以和Visual Studio.net（ASP）竞争。那等于以己之短，较人之长。
而且，一个潜在的危险是，Java Web开发框架将被引上一条微软倡导的“C/S结构、桌面客户端”的不归之路。

目前的一个趋势是，B/S开发框架尽量向C/S开发框架靠拢。
几乎所有的现代Web开发框架都在努力地追求着基于事件机制的处理方式——把前台页面组件和后台处理代码绑定在一起。
Visual Studio.net的ASP开发工具是一个典型的类C/S的B/S开发结构。JSF的Webapp开发工具部分也亦步亦趋，跟着走上了这条路。
不仅在服务端的开发框架存在这种趋势，在客户端这种趋势也愈演愈烈。继ActiveX，Applet之后， XMLHTTP，FLEX等新一代的“浏览器插件客户端技术”方兴未艾。
开源社区Mozilla提出并支持XUL技术。微软的LongHorn 64位操作系统提出“桌面即浏览器”（其实等于宣告浏览器的消亡），力推XAML。
HTML不被双方看好。HTML前景堪忧。
一种可能性：将来HTML很可能只作为一种历史资料的记录格式而存在，而不会作为应用程序的UI存在；而HTML浏览器也只将作为一种历史资料查看器而存在；HTML B/S Webapp时代结束。

可以说， B/S Webapp正是毁于自身越来越复杂的内需和开发结构。
B/S Webapp的界面的互操作性要求越来越强，浏览器需要支持的特性越来越多，附带的插件也越来越多（Java Script，ActiveX，Flash，XUL）。既然这样，为什么还用浏览器？Web Service协议比HTTP协议格式更完善，直接用Web Service客户端不是更直接，更彻底？
微软把握并引导这个趋势，Java世界也做好了两手准备。
无论是Visual Studio.net，还是JSF，其重头戏都是支持Web Service应用程序开发。毕竟，Web Service是属于未来两年的技术。

Web将变得越来越来越强大，无处不在。Semantic Web更有效地把整个Web资源组织为一个巨大的文档库、数据库、资料库和服务库。在这个大好形势下，主角将是各种Web Service Agent，而现在正当红的主角——HTML B/S Webapp却面临着将来（几年）出局的可能。（呵呵，先别急着说这是危言耸听，我只是假设这样的可能性）

倾巢之下，岂有完卵？
如果HTML B/S Webapp消亡了。大量的HTML TagLib就随之淘汰了。Tapestry，XMLC，Echo也随之淘汰了。
XML + XSLT的项目也许还能够幸存——比如，改造XSL，输出XUL或XAML。