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所示的這類龐大的構想）。

WEUI包括了B/S兩端的設計，甚至還有自己的一個開發環境。而真正做起來的時候，則是從WEUI OOP Framework開始的。這是因為JavaScript語言沒有真正的“面向對象編程（Object Oriented Programming, OOP）”框架。

在我所收集的資料中，第一個提出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所示。

Bindows可能也是趕上了好時候，這年的MS Teched就有好幾個專場來講述智能客戶端（Smart Client）。而智能客戶端的基本思想就是跨平臺的、彈性的富客戶端（Rich Client）。因此“豐富的瀏覽器表現”立即成為“時新”的開發需求，以Bindows為代表的RWC也因此成為國內開發者和需求方共同關注的焦點。

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月。

1.3.2 重寫框架的語言層

Qomo項目于2005年末啟動，它自一開始便立意于繼承和發展WEUI框架。為此我聯系了WEUI原項目組以及產品所有的公司，并獲得了基于該項目開源的授權。

從WEUI到Qomo轉變之初，我只是試圖整理一套有關WEUI的文檔，并對WEUI內核中有關OOP的部分做一些修補。因此在這個階段，我用了一段時間撰寫公開文檔來講述JavaScript的基本技術，這包括一組名為《JavaScript面向對象的支持》的文章。而這個過程正好需要我深入地分析JavaScript對象機制的原理，以及這種原理與Qomo項目中對OOP進行補充的技術手段之間的關系。然而這個分析的過程，讓我汗如雨下：在此以前，我一直在用一種基于Delphi的面向對象思想的方式，來理解JavaScript中的對象系統的實現。這種方式完全忽略了JavaScript的“原型繼承”系統的特性，不但棄這種特性優點于不顧，而且很多實現還與它背道而馳。換而言之，WEUI中對于OOP的實現，不但不是對JavaScript的補充，反而是一種傷害。

于是，我決定重寫WEUI框架的語言層。不過在做出這個決定時，我仍然沒有意識到WEUI的內部其實還存在著非常多的問題——這其中既有設計方面的，也有實現方面的問題。但我已經決定在WEUI向Qomo轉化的過程中，圍繞這些（已顯現或正潛藏著的）問題開始努力了。

Qomo Field Test 1.0發布于2006年2月中旬，它其實只包括一個$import()函數的實現，用于裝載其他模塊。兩個月之后終于發布了beta 1，已經包括了兼容層、命名空間，以及OOP、AOP、IOP三種程序設計框架基礎。這時Qomo項目組發展到十余人，部分人員已經開始參與代碼的編寫和審查工作了。我得到了Zhe的有力支持，他幾乎獨立完成了兼容層框架以及其在Mozilla、Safari等引擎上的兼容代碼。很多開源界的，或者對JavaScript方面有豐富經驗的朋友對Qomo提出了他們的建議，包括我后來的同事hax等。這些過程貫穿于整個Qomo開發過程之中。

在經歷過兩個beta之后，Qomo趕在2007年2月前發布了v1.0 final。這個版本包括了Builder系統、性能分析與測試框架，以及公共類庫。此外，該版本也對組件系統的基本框架做出了設計，并發布了Qomo的產品路線圖，從而讓Qomo成為一個正式可用的、具有持續發展潛力的框架系統。

回顧WEUI至Qomo的發展歷程，后者不單單是前者的一個修改版本，而幾乎是在相同概念模型上的、完全不同的技術實現。Qomo摒棄了對特殊的或具體語言環境相關特性的依賴，更加深刻地反映了JavaScript語言自身的能力。不但在結構上與風格上更為規范，而且在代碼的實用性上也有了更大的突破。即使不討論這些（看起來有些像宣傳詞的）因素，僅以我個人而言，正是在Qomo項目的發展過程中，加深了我對JavaScript的函數式、動態語言特性的理解，也漸而漸之地豐富了本書的內容。

1.3.3 富瀏覽器端開發與AJAX

事情很快發生了變化——起碼，看起來時代已經變了。因為從2005年開始，幾乎整個B/S開發界都在熱情地追捧一個名詞：AJAX。

AJAX中的“J”就是指JavaScript，它明確地指出這是一種基于JavaScript語言實現的技術框架。但事實上它很簡單，如果你發現它的真相不過是“使用一個對象的方法而已”，那么你可能會不屑一顧。因為如果在C++、Java或Delphi中，有人提出一個名詞/概念（例如Biby），說“這是如何使用一個對象的技術”，那絕不可能得到如AJAX般的待遇。

然而，就是這種“教你如何用一個對象”的技術在2005年至2006年之間突然風行全球。Google基于AJAX構建了Gmail；微軟基于AJAX提出了Atlas; Yahoo發布了YUI（Yahoo! User Interface）; IBM則基于Eclipse中的WTP（Web Tools Project）發布了ATF（AJAX Toolkit Framework）……一夜之間，原本在技術上對立或者競爭的公司都不約而同地站到了一起：它們不得不面對這種新技術給互聯網帶來的巨大機會。

事實上在AJAX的早期就有人注意到這種技術的本質不過是同步執行。而同步執行其實在AJAX出現之前就已經應用得很廣泛：在IE等瀏覽器上采用“內嵌幀（IFrame）”載入并執行代碼；在Netscape等不支持IFrame技術的瀏覽器中采用“層（Layer）”來載入并執行代碼。這其中就有JSRS（JavaScript Remote Scripting），它的第一個版本發布于2000年8月。

但是以類似于用JSRS的技術來實現的HTTP-RPC方案存在兩個問題：

█ Iframe/Layer標簽在瀏覽器中沒有得到廣泛的支持，也不為W3C標準所認可。

█ HTTP-RPC沒有提出數據層的定義和傳輸層的確切實施方案，而是采用B/S兩端應用自行約定協議。

然而這仍然只是表面現象。JSRS一類的技術方案存在先天的不足：它僅僅是技術方案，并不是應用框架，也沒有任何商業化公司去推動這種技術。而AJAX一開始就是具有成熟商業應用模式的框架，而且許多公司快速地響應了這種技術并基于它創建了各自的“同步執行”的解決方案和編程模型。因此真正使AJAX浮上水面的并不是“一個XMLHttpRequest對象的使用方法”，也并不因為它是“一種同步和異步載入遠程代碼與數據的技術”，而是框架和商業標準所帶來的推動力量。

這時人們似乎已經忘卻了RWC。而W3C卻回到了這個技術名詞上，并在三個主要方面對RWC展開了標準化的工作：

█ 復合文檔格式（Compound Document Formats, CDF）。

█ Web標準應用程序接口（Web APIs）。

█ Web標準應用程序格式（Web Application Formats）。

這其中，CDF是對AJAX中的“X”（即XML）提出標準；而Web APIs則試圖對“J”（即JavaScript）提出標準。所以事實上，無論業界如何渲染AJAX或者其他的技術模型或框架，Web上的技術發展方向仍然會落足到“算法+結構”這樣的模式上來。這種模式在瀏覽器上的表現，后者是由XML/XHTML標準化來實現的，而前者就是由JavaScript語言來驅動的。

微軟當然不會錯過這樣的機會。微軟開始意識到Flash已經成為“基于瀏覽器的操作平臺”這一發展方向上不可忽視的障礙，因此一方面發展Altas項目，為．NET Framework+ASP.NET+VS.NET這個解決方案解決RWC開發中的現實問題，另一方面，啟動被稱為“Flash殺手”的Silverlight項目對抗Adobe在企業級、門戶級富客戶端開發中推廣RIA思想。

現在，編程語言體系也開始發生根本性的動搖。Adobe購得Macromedia之后，把基于JavaScript規范的ActionScript回饋給開源界，與Mozilla開始聯手打造JavaScript 2;SUN在Java 6的JSR-223中直接嵌入了來自Mozilla的Rhino JavaScript引擎，隨后Java自己也開源了。在另一邊，微軟借助．NET虛擬執行環境在動態執行上天生的優勢，全力推動DLR（Dynamic Language Runtime），其中包括了Ruby、Python、JavaScript和VB等多種具有動態的、函數式特性的語言實現，這使得．NET Framework一路沖進了動態語言開發領域的角斗場。