1.4 語言的進(jìn)化

1.4.1 Qomo的重生

這時(shí)的Qomo已經(jīng)相當(dāng)完整地實(shí)現(xiàn)了一門“高級語言”的大多數(shù)特性，我一時(shí)間卻覺得Qomo失去了它應(yīng)有的方向。原本作為產(chǎn)品的一個(gè)組成部分的WEUI是有著它的商業(yè)目的的，而Qomo v1.x～v2.0的整個(gè)發(fā)展過程中也有著“開源框架”這樣的追求。但當(dāng)這些目的漸漸遠(yuǎn)去的時(shí)候，Qomo作為一個(gè)沒有商業(yè)和社區(qū)推動(dòng)的項(xiàng)目，該如何發(fā)展呢？

我已經(jīng)不止一次地關(guān)注到了Qomo核心部分的復(fù)雜性。在Qomo v2以前，這些復(fù)雜性由瀏覽器兼容、代碼組織形式和語言實(shí)現(xiàn)技術(shù)三個(gè)方面構(gòu)成。舉例來說，考慮到Qomo的代碼包可以自由地拼裝，因此Interface層的實(shí)現(xiàn)就必須要能夠完整地從整個(gè)框架中剝離出去；另一方面，Interface層又必須依賴OOP層中所設(shè)計(jì)的對象實(shí)現(xiàn)框架。這使得Qomo v2不得不在Loader框架中加入了一種類似編譯器的“內(nèi)聯(lián)（Inline）”技術(shù)，也就是在打包的時(shí)候，將一些代碼直接插入指定的位置，以黏合跨層次之間的代碼實(shí)現(xiàn)。

Inline帶來的惡果之一，就是原本的Object.js被分成了9個(gè)片斷—當(dāng)使用不同的選項(xiàng)來打包的時(shí)候，這些片斷被直接拼接到一個(gè)大的文件中；當(dāng)使用動(dòng)態(tài)加載方式裝入Qomo的時(shí)候，可以用“Inline”的方式在使用eval()執(zhí)行代碼文本的同時(shí)插入這些片斷。

我意識到我在觸碰一種新的技術(shù)的邊界。這一技術(shù)的核心問題是：一個(gè)框架的組織原則與實(shí)現(xiàn)之間的矛盾。

Qomo到底應(yīng)該設(shè)計(jì)為何種框架？是為應(yīng)用而設(shè)計(jì)，還是僅僅圍繞語言特性的擴(kuò)展？在不同的選擇之下，Qomo又應(yīng)該被實(shí)現(xiàn)成什么樣子？

在2007年年末，我開啟了一個(gè)新的項(xiàng)目，名為QoBean。

1.4.2 QoBean是對語言的重新組織

QoBean將問題直接聚焦于“語言實(shí)現(xiàn)”，開始討論JavaScript語言自身特性的架構(gòu)方式、擴(kuò)展能力以及新語言擴(kuò)展的可能性。緣于這一設(shè)定，QoBean將Qomo中的語言層單獨(dú)拿了出來，并設(shè)定了一些基本原則：

■ 不討論瀏覽器層面的問題。

■ 在ECMAScript規(guī)范的基礎(chǔ)上實(shí)現(xiàn)，以保證可移植性。

■ 可以完全、透明地替換Qomo中的語言層。

■ 從語言原子做起。

“從語言原子做起”意味著它必須回歸到對JavaScript語言的重新思考，即究竟什么才是JavaScript語言的“原子”。

“語言原子”這個(gè)詞我最早讀自李戰(zhàn)的《悟透Delphi》。不過這本書終究沒出，而李戰(zhàn)兄后來寫了一本《悟透JavaScript》，算是完成了他的“悟透”。至于引發(fā)我關(guān)于JavaScript原子問題思考的，則是在本書第一版出版的前后，與宋興烈談到JavaScript的一些特性，而他便提議將這些東西視作“原子特性”。

“這些東西”其實(shí)只有兩個(gè)，其一是對象，其二是函數(shù)。它們初次在QoBean中的應(yīng)用，便是“以極小的代價(jià)實(shí)現(xiàn)Qomo的整個(gè)類繼承框架的完整體系”。而這一嘗試的結(jié)果是：原本在Qomo中用了565行代碼來實(shí)現(xiàn)的Object.js，在QoBean的描述中卻只用了20行代碼。進(jìn)一步地，在新的QoBean中，為OOP語言層做的概念描述也只剩下了兩行代碼：

元語言的概念在Qomo/QoBean中漸漸浮現(xiàn)出來。2008年7月，即在發(fā)布QoBean alpha 1之后的半年，我為QoBean撰寫了兩篇博客文章：QoBean的元語言系統(tǒng)（一）、（二）。QoBean也在此時(shí)基本完成了對“Qomo的語言層”的重新組織。

事實(shí)上，QoBean本質(zhì)上探討了JavaScript這門語言的一種擴(kuò)展模式，即基于語言自身的原子特性進(jìn)行二次實(shí)現(xiàn)的能力。這與后來的其他一些語言擴(kuò)展，盡管行進(jìn)在完全不同的道路上，但卻有著基本相同的目的。

我們在探索的是JavaScript這門語言的邊界。

1.4.3 JavaScript作為一門語言的進(jìn)化

JavaScript之父Brendan Eich曾說：“我們最初利用JavaScript的目的，是讓客戶端的應(yīng)用不必從服務(wù)器重新加載頁面即可回應(yīng)用戶的輸入信息，并且給腳本編寫者提供一種功能強(qiáng)大的圖形工具包。”這包括要在客戶端實(shí)現(xiàn)的兩個(gè)方面的功能，第一是用戶交互，第二是用戶界面（UI）。而展現(xiàn)與交互，正是現(xiàn)在對“前端職能”的兩個(gè)主要定義。所以這門語言的最初構(gòu)想，與它現(xiàn)在所應(yīng)用的主要領(lǐng)域是悄然契合的。

但在2000年之后，瀏覽器取代傳統(tǒng)的操作系統(tǒng)桌面漸漸成為熱門的“客戶端”解決方案，AJAX在這時(shí)作為一種客戶端技術(shù)對這一技術(shù)選型起到了推波助瀾的作用。與此同時(shí)，開發(fā)人員覺察到JavaScript作為一門語言—在客戶端實(shí)現(xiàn)技術(shù)中—難以有足夠豐富的實(shí)現(xiàn)能力。于是語言級別的擴(kuò)展紛紛出現(xiàn)：在代碼組織上，開始有了名字空間；在運(yùn)行效率上，有了編譯壓縮；在標(biāo)準(zhǔn)化方面，有了Common JS；在語言擴(kuò)展上，有了在JavaScript中嵌入的解釋語言……

對于傳統(tǒng)的高級程序設(shè)計(jì)語言來講，這一切再自然不過了。然而JavaScript畢竟只是一種腳本語言，這些“附加的”擴(kuò)展與“第三方的”實(shí)現(xiàn)事實(shí)上帶來了更大的混亂。于是大公司開始提出種種“統(tǒng)一框架”，或者兼容并包的“整合方向”。在這一選擇中，大公司首先解決的是“自己的”問題，這是由于在它們的種種產(chǎn)品、產(chǎn)品線中尤其需要這樣一種統(tǒng)一的、標(biāo)準(zhǔn)的方案，以避免重復(fù)投入帶來的開發(fā)與維護(hù)成本。因此，“商業(yè)化產(chǎn)品+自主的JavaScript開發(fā)包”成為一種時(shí)興的產(chǎn)品模式。在這一產(chǎn)品模式中，由于JavaScript本身不具有源碼保護(hù)的特性，因此源碼開放既是戰(zhàn)略，又是手段，也是不得已而為之的事。

現(xiàn)在我們有了機(jī)會(huì)看到Plam手機(jī)平臺上完整的Web OS的代碼，也有機(jī)會(huì)直接讀到FireBug中全部用于支持引擎級調(diào)試的代碼，手邊還有類似YUI、Dojo等的企業(yè)級框架可用。然而，一切還是一如既往的混亂。因?yàn)椋@一切只是基于語言的擴(kuò)展，而非語言或其基礎(chǔ)庫中的特性。造成這一事實(shí)的原因，既源于JavaScript自身初始設(shè)計(jì)的混合式特性，也因?yàn)镋CMA在這門語言的標(biāo)準(zhǔn)化工作上的滯后與反復(fù)。

JavaScript在發(fā)布v1.0的時(shí)候，僅有結(jié)構(gòu)化語言的特性以及一些基礎(chǔ)的面向?qū)ο筇匦裕磗tructured and object based programming）。到v1.3時(shí)有了本質(zhì)性的改觀，使得這一語言成為包括動(dòng)態(tài)語言、函數(shù)式語言特性在內(nèi)的特性豐富的混合語言。這一切被ECMA通過標(biāo)準(zhǔn)化的形式確定下來，形成了以JavaScript 1.5和ECMAScript Ed3版本（即JS1.5/ES3.1）為代表的，一直到我們今天仍在使用的JavaScript語言。

隨后ECMA啟動(dòng)了一個(gè)工作組來進(jìn)行下一代JavaScript的標(biāo)準(zhǔn)化工作，稱為ECMAScript Ed4（即ES4/JS2），這個(gè)小組的工作始于2003年3月。然而它們搞砸了整件事，它們幾乎把JS2設(shè)計(jì)成了一門新的、大的、復(fù)雜的語言。因此，一方面一些需要“豐富的語言特性”的廠商不遺余力地推進(jìn)著這一標(biāo)準(zhǔn)，另一方面它又被崇尚簡捷的前端開發(fā)人員詬病不已。遲至2009年年底，ECMA Ed4的標(biāo)準(zhǔn)化小組終于宣布：ES4的標(biāo)準(zhǔn)化暫停，并將基于ES4的后續(xù)工作稱為ECMAScript Harmony。接下來，為了解決“互聯(lián)網(wǎng)開發(fā)需要更新的、標(biāo)準(zhǔn)化的JavaScript語言”這一迫切問題，不久它們就發(fā)布了ECMAScript Ed5這一版本，即ES5。JavaScript的發(fā)展歷程如圖1-6所示。

嚴(yán)格地說，ES5與ES4基本沒有什么關(guān)系，而是對ES3.1所代表的語言方向的一個(gè)補(bǔ)充。換言之，ES5沒有改變JavaScript 1.x的語言特性，而ES4則是一門集語言生產(chǎn)商所有創(chuàng)想之大成且又與JavaScript 1.x倡導(dǎo)的語言風(fēng)格相去甚遠(yuǎn)的語言。歷史證明，我們暫時(shí)拋棄了后者—過去10年，我們都未能將JavaScript 1.x推進(jìn)到v2.0版本。

由于ES5秉承了JavaScript設(shè)計(jì)的原始思想，因此基于ES5又展開了新一輪的語言進(jìn)化的角力（圖1-6中的三條虛線試圖說明，語言最初的特性設(shè)計(jì)是這一切的根源）：

■ 第一個(gè)方向由Microsoft、Adobe等大廠商所主導(dǎo)，沿著ES4—或稱為JS2、或ECMAScript Harmony—的方向，向更加豐富的面向?qū)ο螅∣O++）特性發(fā)展，主要試圖解決大型系統(tǒng)開發(fā)中所需要的復(fù)雜的對象層次結(jié)構(gòu)、類庫以及框架。

■ 第二個(gè)方向，則由包括Brendan Eich本人在內(nèi)的語言開發(fā)者、研究者主導(dǎo)，他們力圖增強(qiáng)JavaScript語言的函數(shù)式特性（Functional++），因?yàn)檫@樣的語言特性在解決許多問題時(shí)來得比結(jié)構(gòu)化的、面向?qū)ο蟮恼Z言更優(yōu)雅有效，而且從語言角度看來，函數(shù)式更為“純粹”。

■ 在第三個(gè)方向上，Common JS等開發(fā)組意識到JS1.x在應(yīng)用于瀏覽器之外的開發(fā)場景中，以及在組織大型項(xiàng)目方面顯得無力。而將這一問題歸結(jié)起來，就是“缺乏基礎(chǔ)運(yùn)行框架和運(yùn)行庫”，于是通過參考傳統(tǒng)的、大型的、系統(tǒng)級的應(yīng)用開發(fā)語言，嘗試性地提出了在JavaScript中的同等解決方案（System++）。

具體的引擎或框架已經(jīng)不再是被關(guān)注的話題。ES4的失敗給整個(gè)JavaScript領(lǐng)域帶來的思考是：我們究竟需要一種怎樣的語言？