XUL Runner 的反思

几年以前可能很少有人想到Java-script现在能成为端上席面的大餐了，那时我还煞有介事买了那本著名的《精通EJB》拿来啃，觉得越是深奥的东西将来越有前途。而现在是“简单化”的时代，用编程的方法做UI已经逐渐落后，而基于XML描述式的方法逐渐成为主流，Semi-rich client成为了大公司竟相研究的热点问题。

在热点之中有一个本来应该很有潜力的技术，就是 Mozilla的XUL Runner。XUL Runner被设计成一种可以支持“轻量级”UI的平台，所谓轻量，是和那些用Native widget来构造UI的技术，如Eclipse的SWT，以及SUN的AWT相对应的。不用系统提供的widget，那就自己画。Swing/Draw2D都属于这样的技术。用XUL Runner来画widget应该是驾轻就熟的事情，因为它天然就具有了渲染HTML的能力，自然也能扩展一下渲染其他的东西，比如X-Form, SVG, MathML，都是Mozilla网站上声明支持的东西。除了画静态的UI，还应该具有一些动态特性，XUL Runner天然含有Java script引擎，在XML里面嵌入脚本语言，用脚本来动态修改DOM树，从而实现动态特征。

有了这样一个天然支持HTML/XUL和java script的基础平台，如果加上一些可扩展特性，比如集成JAVA，C++既有程序的能力，不就是一个很好的桌面应用基础平台吗？而XUL Runner也的确提供了这样的东西，就是XPCOM。最大的问题就是XPCOM实在太难学，而且是以C++为基础的。如果想用JAVA，实际上还要通过一个JNI写的Bridge程序来完成。

那么，想要让XPCOM好用起来，就需要在这个JAVA-XPCOM bridge上面再做一个IOC的封装，让人们可以通过XML来对对象进行实力化，但是这就又回到了Java低性能的老路上了。当我们操作一个UI对象时，实际的工作是先有一个Java 反射的动作，然后是JNI调用到XPCOM，XPCOM再调到Gekeo，Gekeo最终调用Win32 GDI函数来工作。
这样下来弄不好比ECLIPSE还慢。

到底有什么办法让我们既有软件工程化的享受，又有性能上的舒适？这应该是Architect要面对的大问题了。