1.3 沒有框架與庫的語言能怎樣發(fā)展呢

1.3.1 做一個框架

聊天室接下來的發(fā)展幾乎停滯了。我在RWC與RIA之爭中選擇了RWC，但同時也面臨著RWC的困境：我找不到一個統(tǒng)一的框架或底層環(huán)境。因此，聊天室如果再向下發(fā)展，也只能是在代碼堆上堆砌代碼而已。

于是，整個2003年，我基本上都沒有再碰過瀏覽器上的開發(fā)。2004年年初的時候，我到一家新的公司任職。這家公司的主要業(yè)務(wù)都是B/S架構(gòu)上的開發(fā)，于是我提出“先做易做的1/2”的思路，打算通過提高瀏覽器端的開發(fā)能力，來加強公司在B/S架構(gòu)開發(fā)中的競爭力。

于是我得到很豐富的資源來主持一個名為WEUI（Web Enterprise UI Component Framework）項目的開發(fā)工作。這個項目的最初設(shè)想，跟JSVPS一樣是一個龐然大物（似乎我總是喜歡如圖1-4所示的這類龐大的構(gòu)想）。

WEUI包括B/S兩端的設(shè)計，甚至還有自己的一個開發(fā)環(huán)境。而它真正做起來的時候，則是從WEUI OOP Framework開始的。這是因為JavaScript語言沒有真正的“面向?qū)ο缶幊蹋∣OP）”的框架。

在我所收集的資料中，第一個提出OOP JavaScript概念的是Brandon Myers，他在一個名為Dynapi的開源項目工作中，提出了名為SuperClass的概念和原始代碼。后來，在2001年3月，Bart Bizon按照這個思路發(fā)起了開源項目SuperClass，放在SourceForge上。這份代碼維護(hù)到v1.7b。半年后，Bart Bizon放棄了SuperClass并重新發(fā)起JSClass項目，這成為JavaScript早期框架中的代表作品。

后來許多JavaScript OOP Framework都不約而同地采用了與SuperClass類同的方法—使用“語法解釋器”—來解決框架問題。然而前面提到過的實現(xiàn)了“類Outlook界面”的Erik Arvidsson則采用了另一種思路——使用JavaScript原生代碼（native code）在執(zhí)行期建立框架，并將這一方法用在了另一個同樣著名的項目Bindows上。

對于中國的一部分JavaScript愛好者來說，RWC時代開始于《程序員》雜志2004年第5期的一篇名為《王朝復(fù)辟還是浴火重生—The Return of Rich Client》的文章，這篇文章講的就是Bindows（見圖1-5）。

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

WEUI v1.0內(nèi)核的研發(fā)工作大概就結(jié)束于此時。我在這個階段中主要負(fù)責(zé)的就是JavaScript OOP Language Core的開發(fā)，并基本完成了對JavaScript語言在OOP方面的補充。而接下來，另外兩名開發(fā)人員則分別負(fù)責(zé)Application Framework與Database Layer的開發(fā)，他們的工作完成于2004年8月。緊接著，WEUI就被應(yīng)用到一個商業(yè)項目的前期開發(fā)中了—WEUI很快顯示出它在瀏覽器端的開發(fā)優(yōu)勢：它擁有完整的OOP框架與“基本夠用”的組件庫，為構(gòu)建大型的瀏覽器端應(yīng)用系統(tǒng)的可行性提供了實證。

WEUI在開發(fā)環(huán)境和服務(wù)器端上沒有得到投入。這與JSVPS有著基本相同的原因：沒有需求。于是從2004年年底開始，我就著手以UI組件庫為主要目標(biāo)的WEUI v2.0的開發(fā)，直到2005年3月。

1.3.2 重寫框架的語言層

Qomo項目于2005年年末啟動，它一開始便立意于繼承和發(fā)展WEUI框架。為此，我聯(lián)系了WEUI原項目組以及產(chǎn)品所屬的公司，并獲得了基于該項目開源的授權(quán)。

從WEUI到Qomo的轉(zhuǎn)變之初，我只是試圖整理一套有關(guān)WEUI的文檔，并對WEUI內(nèi)核中有關(guān)OOP的部分做一些修補。因此在這個階段，我用了一段時間撰寫公開文檔來講述JavaScript的基本技術(shù)，這包括一組名為《JavaScript面向?qū)ο蟮闹С帧返奈恼?。而這個過程正好需要我深入地分析JavaScript對象機制的原理，以及這種原理與Qomo項目中對OOP進(jìn)行補充的技術(shù)手段之間的關(guān)系。然而這個分析的過程讓我汗如雨下：在此以前，我一直在用一種基于Delphi的面向?qū)ο笏枷氲姆绞剑瑏砝斫釰avaScript中的對象系統(tǒng)的實現(xiàn)。這種方式完全忽略了JavaScript的“原型繼承”系統(tǒng)的特性，不但棄這種優(yōu)點于不顧，而且很多實現(xiàn)還與它背道而馳。換言之，WEUI中對于OOP的實現(xiàn)，不但不是對JavaScript的補充，反而是一種傷害。

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

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

在經(jīng)歷過兩個beta之后，Qomo趕在2007年2月前發(fā)布了v1.0 final。這個版本包括了Builder系統(tǒng)、性能分析與測試框架，以及公共類庫。此外，該版本也對組件系統(tǒng)的基本框架做出了設(shè)計，并發(fā)布了Qomo的產(chǎn)品路線圖，從而讓Qomo成為一個正式可用的、具有持續(xù)發(fā)展?jié)摿Φ目蚣芟到y(tǒng)。

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

1.3.3 富瀏覽器端開發(fā)（RWC）與AJAX

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

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

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

事實上，在AJAX出現(xiàn)的早期，就有人注意到這種技術(shù)的本質(zhì)不過是同步執(zhí)行。而“同步執(zhí)行”其實在AJAX出現(xiàn)之前就已經(jīng)應(yīng)用得很廣泛了：在Internet Explorer等瀏覽器上采用“內(nèi)嵌幀（IFrame）”載入并執(zhí)行代碼；在Netscape等不支持IFrame技術(shù)的瀏覽器中采用“層（Layer）”來載入并執(zhí)行代碼。這其中還有JSRS（JavaScript Remote Scripting），它的第一個版本發(fā)布于2000年8月。

但是以類似用JSRS的技術(shù)來實現(xiàn)的HTTP-RPC方案存在兩個問題：

■ IFRAME/LAYER標(biāo)簽在瀏覽器中沒有得到廣泛支持，也不被W3C標(biāo)準(zhǔn)所認(rèn)可。

■ HTTP-RPC沒有提出數(shù)據(jù)層的定義和傳輸層的確切實施方案，而是采用B/S兩端應(yīng)用自行約定協(xié)議的方式。

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

這時人們似乎已經(jīng)忘記了RWC。而W3C卻回到了這個技術(shù)名詞上，并在三個主要方面對RWC展開了標(biāo)準(zhǔn)化的工作：

■ 復(fù)合文檔格式（Compound Document Formats，CDF）。

■ Web標(biāo)準(zhǔn)應(yīng)用程序接口（Web API）。

■ Web標(biāo)準(zhǔn)應(yīng)用程序格式（Web Application Format）。

這其中，CDF是對AJAX中的“X”（即XML）提出標(biāo)準(zhǔn)；而Web API則試圖對“J”（即JavaScript）提出標(biāo)準(zhǔn)。所以事實上，無論業(yè)界如何渲染AJAX或者其他的技術(shù)模型或框架，Web上的技術(shù)發(fā)展方向，仍然會落足到“算法+結(jié)構(gòu)”這樣的模式上。這種模式在瀏覽器上的表現(xiàn)，后者是由XML/XHTML標(biāo)準(zhǔn)化來實現(xiàn)的，而前者就是由JavaScript語言來驅(qū)動的。

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

此時，基于虛擬機而不是直接編譯到native的方式已經(jīng)成了執(zhí)行環(huán)境的主流，因此編程語言體系也開始發(fā)生根本性的動搖。Adobe購得Macromedia之后，把基于JavaScript規(guī)范的ActionScript回饋給開源界，與Mozilla開始聯(lián)手打造JavaScript 2；SUN在Java 6的JSR-223中直接嵌入來自Mozilla的Rhino JavaScript引擎，隨后Java自己也開源了。在另一邊，微軟借助.NET虛擬執(zhí)行環(huán)境在動態(tài)執(zhí)行上天生的優(yōu)勢，全力推動DLR（Dynamic Language Runtime），其中包括Ruby、Python、JavaScript、VB等多種具有動態(tài)的、函數(shù)式特性的語言實現(xiàn)，這使得.NET Framework一路沖進(jìn)了動態(tài)語言開發(fā)領(lǐng)域的角斗場。