1.3.1 做一个框架

1.3  没有框架与库的语言能怎样发展呢？

1.3.1  做一个框架

聊天室接下来的发展几乎停滞了。我在RWC与RIA之争中选择了RWC，但也同时面临了RWC的困境：我找不到一个统一的框架或底层环境。因此，聊天室如果再向下发展，也只能是在代码堆上堆砌代码而已。

于是，整个的2003年，我基本上都没有再碰过浏览器上的开发。2004年初的时候，我到一家新的公司（Jxsoft Corporation）任职。这家公司的主要业务都是B/S架构上的开发，于是我提出“先做易做的1/2”的思路，打算通过提高浏览器端开发能力，来加强公司在B/S架构开发中的竞争力。

于是我得到很丰富的资源，来主持一个名为WEUI（Web Enterprise UI Component Framework）项目的开发工作。这个项目的最初设想，跟JSVPS一样是个庞然大物（似乎我总是喜欢如图1-4所示的这类庞大的构想）。

图1-4  WEUI基本框架和技术概览

WEUI包括了B/S两端的设计，甚至还有自己的一个开发环境。而真正做起来的时候，则是从WEUI OOP Framework开始的。这是因为JavaScript语言没有真正的“面向对象编程（OOP，Object Oriented Programming）”框架。
在我所收集的资料中，第一个提出OOP JavaScript概念的是Brandon Myers，他在一个名为Dynapi 的开源项目工作中，提出了名为“SuperClass”的概念和原始代码。后来，在2001年3月，Bart Bizon按照这个思路发起了开源项目SuperClass，放在SourceForge上。这份代码维护到ver 1.7b。半年后，Bart Bizon放弃了SuperClass并重新发起JSClass项目，这成为JavaScript早期框架中的代表作品。

后来许多的JavaScript OOP Framework都不约而同地采用了与SuperClass类同的方法——使用“语法解释器”——来解决框架问题。然而前面提到过的实现了“类Outlook界面”的Erik Arvidsson则采用了另一种思路：使用JavaScript原生代码（native code）在执行期建立框架，并将这一方法用在了另一个同样著名的项目Bindows上。

对于中国的一部分的JavaScript爱好者来说，RWC时代就开始于《程序员》2004年第5期的一篇《王朝复辟还是浴火重生——The Return of Rich Client》。这篇文章讲的就是Bindows（见图1-5）。

图1-5  Bindows在浏览器上的不凡表现

Bindows可能也是赶上了好时候，这年的MS Teched就有好几个专场来讲述智能客户端（Smart Client）。而“智能客户端”的基本思想就是跨平台的、弹性的富客户端（Rich Client）。因此“丰富的浏览器表现”立即成为“时新”的开发需求，以Bindows为代表的RWC（Rich Web Client）也因此成为国内开发者和需求方共同关注的焦点。

WEUI v1.0内核的研发工作大概就结束于此时。我在这个阶段中主要负责的就是JavaScript OOP Language Core的开发，并基本完成了对JavaScript语言在OOP方面的补充。而接下来，另外的两名开发人员 则分别负责Application Framework与Database Layer的开发，他们的工作完成于2004年8月。紧接着WEUI就被应用到一个商业项目的前期开发中了——WEUI很快显示出它在浏览器端的开发优势：它拥有完整的OOP框架与“基本够用”的组件库，为构建大型的浏览器端应用系统的可行性提供了实证。

WEUI在开发环境和服务器端上没有得到投入。这与JSVPS有着基本相同的原因：没有需求。于是从2004年底开始，我就着手以UI组件库为主要目标的WEUI v2.0的开发，直到2005年3月。