大型JavaScript Web應(yīng)用程序很可能既難于開發(fā)、又運行緩慢。相比之下，谷歌的Dart語言針對這兩大難題給出了解決方案。

JavaScript如今的主要應(yīng)用方式與其最初定位可謂風(fēng)馬牛不相及：當(dāng)下它正作為托管于瀏覽器當(dāng)中的平臺用于大型Web應(yīng)用程序開發(fā)。如果創(chuàng)造JavaScript的技術(shù)人員能夠早點預(yù)見到這類應(yīng)用方式——而不僅僅是為Web頁面增添活力——那么JavaScript的設(shè)計思路很可能完全不同。

這是因為在大型Web應(yīng)用程序的開發(fā)流程中，存在著兩大主要難題。

首先，性能難題：作為無法辯駁的事實，利用JavaScript編寫的大型應(yīng)用程序在運行速度方面相對較慢，這必然會給程序用戶造成負(fù)面影響。

其次，JavaScript本身的結(jié)構(gòu)也存在問題：這是一種語言，因為大型團(tuán)隊很難利用它組織開發(fā)工作。不同模塊之間缺乏明顯的結(jié)構(gòu)以及強有力的聯(lián)系，加之代碼本身的表達(dá)意圖難以付諸溝通，這給開發(fā)團(tuán)隊造成很大困擾。對于個人開發(fā)者，溝通便捷性似乎并不重要；但對于大型項目的開發(fā)團(tuán)隊而言，溝通編碼意圖是保證項目成功的關(guān)鍵所在——尤其是隨著時間推移產(chǎn)生的人員更替，繼任者很可能對遺留代碼感到困惑與迷茫。

大型應(yīng)用程序通常采用模塊化開發(fā)機制，即由不同開發(fā)人員負(fù)責(zé)各自獨立的代碼片段。然而由于JavaScript的動態(tài)特性，對象行為會隨著時間推移發(fā)生變化，這與C、C++、Java或者C#完全不同，意味著大家需要通過執(zhí)行代碼來確定其具體作用。

對Web應(yīng)用運行速度的渴求

經(jīng)過長時間的調(diào)整，JavaScript當(dāng)然已經(jīng)擁有了一些令人振奮的速度提升效果，而且五年之后橫空出世的谷歌V8 JavaScript引擎為這款根基孱弱的語言帶來巨大飛躍。但必須承認(rèn)，JavaScript開發(fā)人員仍然受到目前這一代JavaScript引擎的嚴(yán)重束縛，我們恐怕還要等上很久才能迎來下一輪革命性進(jìn)化。

可能的方案之一在于asm.js，這是一套采用高度限制機制的JavaScript子集，最顯著的特征在于舍棄了動態(tài)特性——也就是JavaScript優(yōu)化道路上的最大障礙。

顧名思義，asm.js通常被視為一種針對JavaScript引擎的匯編語言。它目前尚處于測試階段，而且由Mozilla負(fù)責(zé)項目推進(jìn)。

由于它屬于JavaScript的子集，因此擁有全面向下兼容現(xiàn)有JavaScript引擎的能力。另外，能夠與asm.js協(xié)作的引擎在運行速度上也遠(yuǎn)高于普通JavaScript——其具體速度能夠達(dá)到本地代碼的一半左右。（最新版本的火狐瀏覽器[22版本]能夠支持asm.js優(yōu)化，Mozilla公司的開發(fā)人員網(wǎng)站上也給出了技術(shù)演示材料。）

正如C++或者C#開發(fā)人員在處理對性能要求較高的代碼片段時常常選擇低級語言，asm.js也可以成為JavaScript開發(fā)人員的備選方案——大部分是游戲開發(fā)者——并成為創(chuàng)建關(guān)鍵性能代碼片段的理想途徑。沒錯，不太可能會有開發(fā)人員愿意用它開發(fā)整個應(yīng)用程序，但它確實能讓代碼中的某些子集擁有理想的運行速度。

事實上，大多數(shù)開發(fā)人員可能從來不會直接使用asm.js。他們更可能使用C或者C++（或者利用現(xiàn)有C或C++應(yīng)用程序）而后利用Emscripten轉(zhuǎn)譯器將代碼編譯為asm.js。

大型Web應(yīng)用程序開發(fā)

雖然有能力帶來速度提升，但在利用JavaScript開發(fā)大型Web應(yīng)用程序方面，asm.js就幫不上什么忙了。相比之下，幫得上忙的要數(shù)微軟提供的TypeScript方案。從概念上講，TyperScript與asm.js正好相反：asm.js屬于JavaScript的子集，而TypeScript則屬于超集。

這個超集的作用在于為JavaScript開發(fā)流程帶來一定結(jié)構(gòu)，從而通過命令行編譯器利用插件將常規(guī)JavaScript、類型檢查以及Visual Studio 2012加以集成。它的局限性在于無法帶來性能提升：TypeScript編譯而成的JavaScript內(nèi)容與手寫JavaScript內(nèi)容幾乎相同。

Web應(yīng)用程序的速度與規(guī)模

綜上所述，asm.js帶來更理想的運行速度，而TypeScript則提供適用于大型Web應(yīng)用程序的JavaScript開發(fā)環(huán)境。但二者無法同時解決這兩大難題。

而這正是谷歌Dart語言的預(yù)定目標(biāo)。根據(jù)谷歌公司內(nèi)部郵件的說法，Dart希望成為一款“JavaScript的終極替代方案，正如用于Web開發(fā)的通用語在開放Web平臺上的角色。”

[[84969]]

這個目標(biāo)可謂雄心勃勃，那么Dart到底是什么？它是一種開源編程語言，在設(shè)計之初就考慮到了大型應(yīng)用程序開發(fā)以及高運行性能兩大實際需求。事實上，將Dart稱為一種語言并不貼切，因為Dart本身還捆綁有一款驗證器及其它各種開發(fā)工具。由Dart編寫的應(yīng)用程序能夠運行在Dart虛擬機當(dāng)中，且運行速度可達(dá)到瀏覽器上JavaScript速度的兩倍。目前只有谷歌的開源Chomium定制瀏覽器版本才支持Dart，該瀏覽器名為Dartium，但相信Chrome對其實現(xiàn)全面支持將只是時間問題。

編譯為JavaScript

Dart代碼可以通過dart2js編譯器轉(zhuǎn)化為JavaScript內(nèi)容，從而以兼容方式運行在一般瀏覽器當(dāng)中。盡管由Dart編譯而成的JavaScript代碼在運行速度上無法與本地Dart代碼相提并論，但它仍然比開發(fā)人員們?nèi)斯ぞ帉懙腏avaScript代碼快得多，軟件開發(fā)者兼《Dart在行動》一書作者Chris Buckett解釋道。

“當(dāng)代碼由Dart轉(zhuǎn)化為JavaScript時，編譯器所做的類似于搖動樹干以震下枝葉，”Bucket指出。在JavaScript方面，即使只需要其中一項功能、大家也不得不添加一整套庫。但在“搖樹”原則的幫助下，Dart能夠在向JavaScript轉(zhuǎn)化的過程中只納入必要的單項功能而非完整庫。Dart還會對我們的代碼進(jìn)行分析并有選擇地進(jìn)行類型檢查，從而刪除一部分不必存在的內(nèi)容，Buckett表示。而在人工編寫的JavaScript代碼中，我們將被迫以非常保守的方式處理內(nèi)容。

殺手級Dart應(yīng)用

目前除了谷歌公司之外，還沒有哪家瀏覽器供應(yīng)商愿意直接為Dart提供支持，因此Dart成為另一種Web通用語言的可能機微乎其微。不過Buckett認(rèn)為，杰出性能與簡易規(guī)?；_發(fā)兩大優(yōu)勢——外加Dart工具的現(xiàn)有生態(tài)系統(tǒng)——很可能會推動Dart走上普及之路。

“在短期內(nèi)我們還不太可能在其它瀏覽器中看到Dart虛擬機的出現(xiàn)，但如果Dart能夠拿出幾款殺手級應(yīng)用程序成品，而且在Chrome當(dāng)中飛速運行——例如下一個Facebook版本——那么人們很可能希望能在自己的瀏覽器中看到Dart的身影，”Buckett提出假設(shè)。“這種態(tài)勢在移動瀏覽器領(lǐng)域出現(xiàn)的可能性更高，因為JavaScript正是移動設(shè)備電池壽命的主要威脅之一。”

現(xiàn)在JavaScript開發(fā)人員還迎來了另一條好消息——從JavaScript到Dart的技能轉(zhuǎn)化過程非常簡單，不過Dart的編程要求比JavaScript要更嚴(yán)格一些?？偠灾?，任何一位曾經(jīng)利用Java或者C#等服務(wù)器端語言從事過開發(fā)工作的技術(shù)人員都能夠打理好這些額外限制，因此Dart的未來可謂一片光明。

原文鏈接：http://www.cio.com/article/739042/Can_Google_Dart_Solve_JavaScript_s_Speed_and_Scale_Problems_