1.4 語言的進化

1.4.1Qomo的重生

這時的Qomo已經相當完整地實現了一門“高級語言”的大多數特性，我一時間便覺得Qomo失去了它應有的方向。原本作為產品的一個組成部分的WEUI是有著它的商業目的的，而Qomo v1.x~v2.0的整個過程中也有著“開源框架”這樣的追求。但當這些目的漸漸遠去的時候，Qomo作為一個沒有商業和社區推動的項目，該如何發展呢？

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

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

我意識到我在觸碰一種新的技術的邊界。這一技術的核心問題是：一個框架的組織原則與實現之間的矛盾。

Qomo到底應該設計為何種框架？是為應用而設計，還是僅僅圍繞語言特性的擴展？在不同的選擇之下，Qomo又應該被實現成什么樣子？

在2007年末，我開啟了一個新的項目，名為QoBean。

1.4.2 QoBean是對語言的重新組織

QoBean將問題直接聚焦于“語言實現”，開始討論JavaScript語言自身特性的架構方式、擴展能力及新語言擴展的可能性。緣于這一設定，QoBean將Qomo中的語言層單獨地拿了出來，并設定了一些基本原則：

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

█ 在ECMAScript規范的基礎上實現，以保證可移植性。

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

█ 從語言原子做起。

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

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

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

          MetaObject = Function;
          MetaClass = Function;

元語言的概念在Qomo/QoBean中漸漸浮現出來。2008年7月，亦即是在發布QoBean alpha1之后的半年，我為QoBean撰寫了兩篇博客文章：QoBean的元語言系統（一）、（二）。QoBean也在此時基本完成了對“Qomo的語言層”的重新組織。

事實上，QoBean本質上是探討了JavaScript這門語言的一種擴展模式，即基于語言自身的原子特性進行二次實現的能力。這與后來的其他一些語言擴展，有著完全不同的路徑，以及基本相同的目的。

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

1.4.3 JavaScript作為一門語言的進化

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

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

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

現在我們有機會看到Plam手機平臺上完整的Web OS的代碼，也有機會直接讀到FireBug中全部用于支持引擎級調試的代碼，我們手邊還有類似于YUI、Dojo等的企業級框架可用。然而，一切還是一如既往的亂。因為，這一切只是基于語言的擴展，而非語言或其基礎庫中的特性。造成這一事實的原因，既源于JavaScript自身初始設計的混合式特性，也因為ECMA（European Computer Manufacturing Association，歐洲計算機制造協會）在這門語言的標準化工作上的滯后與反復，如圖1-6所示。

圖1-6 JavaScript的語言特性發展及其標準化過程

JavaScript在發布v1.0的時候，僅有結構化語言的特性以及一些基礎的面向對象特性（即Struct + Base OO），這一切直到v1.3的版本時才得以本質性的改觀，使得這一語言成為包括動態語言、函數式語言特性在內的特性豐富的混合語言。這一切被ECMA通過標準化的形式確定下來，形成了以JavaScript 1.5和ECMAScript Ed3版本（即JS 1.5/ES3.1）為代表的，一直到我們今天仍在使用的JavaScript語言。

隨后ECMA啟動了一個工作組來進行下一代JavaScript的標準化工作，稱為ECMAScript Ed4（亦即是ES4/JS2），這個小組的工作始于2003年3月。然而他們搞砸了整件事，他們幾乎把JS2設計成了一門新的、大的、復雜的語言。因此，一方面一些需要“豐富的語言特性”的廠商不遺余力地推進著這一標準，另一方面它又被崇尚輕捷的前端開發人員詬病不已。遲至2009年年底，ECMA Ed4的標準化小組終于宣布：ES4的標準化暫停，并將基于ES4的后續工作稱為ECMAScript Harmony。接下來，為了解決“互聯網開發需要更新的、標準化的JavaScript語言”這一迫切問題，不久他們就發布了ECMAScript 5th這一版本，亦即是ES5。嚴格地說，ES5與ES4基本沒有什么關系，而是對ES3.1所代表的語言方向的一個補充。

換言之，ES5沒有改變JavaScript 1.x的語言特性；ES4則是一門集語言生產商所有創想之大成，而又與JavaScript 1.x倡導的語言風格相去甚遠的語言。歷史證明，我們暫棄了后者——過去10年，我們都未能將JavaScript 1.x推進到v2.0版本。

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

█ 第一個方向由Microsoft、Adobe等大廠商所倡導，沿著ES4——或稱之為JS2、ECMAScript Harmony的方向，向更加豐富的面向對象（OO++）特性發展，主要試圖解決大型系統開發中所需要的復雜的對象層次結構、類庫及框架；

█ 第二個方向，則由包括Brendan Eich本人在內的語言開發者、研究者主導，他們力圖增強JavaScript語言的函數式特性（Functional++），因為這樣的語言特性在解決許多問題時來得比結構化的、面向對象的語言更優雅有效，而且從語言角度看來，函數式更為“純粹”。

█ 在第三個方向上，Common JS等開發組意識到JS 1.x在應用于瀏覽器之外的開發場景中，以及在組織大型項目方面顯得無力。而將這一問題歸結起來，就是“缺乏基礎運行框架和運行庫”，于是通過參考傳統的、大型的、系統級的應用開發語言，嘗試性地提出在JavaScript中的同等解決方案（System++）。

具體的引擎或框架已經不再是被關注的話題。ES4的失敗給整個JavaScript領域帶來的思考是：我們究竟需要一種怎樣的語言？