[[208959]]

這類日常使用的JavaScript Web開發(fā)工具如果想要成為一個(gè)有吸引力的可選方案，至少需要滿足以下三方面的需求：

1.從用戶的角度看，使用工具創(chuàng)建的與原生使用JavaScript開發(fā)的Web站點(diǎn)和應(yīng)用在觀感、頁面加載時(shí)間、頁面啟動(dòng)時(shí)間和持久速度等方面上應(yīng)難以區(qū)分。

2.從開發(fā)人員的角度看，他們希望借助這些工具能夠無縫地訪問其他JavaScript庫，進(jìn)行高效的調(diào)試。

3.從商業(yè)的角度看，應(yīng)不斷有大量的開發(fā)人員愿意接受該工具的專業(yè)培訓(xùn)，并在企業(yè)中使用，學(xué)習(xí)工具所花費(fèi)的時(shí)間應(yīng)能很好地轉(zhuǎn)化為生產(chǎn)力，并且使用該工具創(chuàng)建的應(yīng)用夠滿足不斷變更的需求。

一個(gè)此類轉(zhuǎn)化工具要取得成功，必須要達(dá)到上述三個(gè)方面的需求。各編譯器正盡量在這三個(gè)方面需求間達(dá)到平衡。對(duì)于在日常生產(chǎn)環(huán)境中使用的編譯器來說，其中任何一個(gè)方面都不能被忽略。就Transcrypt而言，這三個(gè)方面的需求都在特定的Transcrypt設(shè)計(jì)決策中起到了決定性作用。

需求一：

Web站點(diǎn)和應(yīng)用的觀感與所用的底層JavaScript庫有直接的關(guān)系。因此想要具有相同的觀感，站點(diǎn)或應(yīng)用必須正確地使用同一軟件庫。

雖然快速的網(wǎng)絡(luò)連接可能會(huì)隱藏其中的差異，達(dá)到同樣的頁面加載時(shí)間，甚至對(duì)于在公共網(wǎng)絡(luò)或托管主機(jī)上運(yùn)行近似大小代碼的移動(dòng)設(shè)備也是如此。這使得在加載每個(gè)新頁面時(shí)，不可能去下載一個(gè)編譯器、虛擬機(jī)或較大的運(yùn)行時(shí)。

只有當(dāng)代碼是在服務(wù)器端靜態(tài)預(yù)編譯成JavaScript時(shí)，才有可能獲得與使用原生JavaScript同樣的頁面啟動(dòng)時(shí)間。頁面中需要的代碼量越大，差別就會(huì)變得愈發(fā)明顯。

要獲得相同的持久速度，必須生成高效的JavaScript代碼。鑒于JavaScript虛擬機(jī)已針對(duì)通用的編程模式做了高度的優(yōu)化，生成的JavaScript應(yīng)該類似于手工編寫的JavaScript，而不是效仿堆棧機(jī)器或是任何其他的底層抽象。

需求二：

要實(shí)現(xiàn)對(duì)所有JavaScript庫的無縫訪問，Python和JavaScript必須使用一致的數(shù)據(jù)格式、一致的調(diào)用模型和一致的對(duì)象模型。一致的對(duì)象模型要求JavaScript的基于原型的單繼承機(jī)制與Python的基于多繼承的機(jī)制融合在一起。應(yīng)注意的是，JavaScript近期添加的關(guān)鍵字“class”對(duì)于彌合這個(gè)根本性的差異需求完全沒有影響。

要實(shí)現(xiàn)高效調(diào)試，必須在源代碼層面完成斷點(diǎn)設(shè)置和代碼單步執(zhí)行這類工作。換句話說，源代碼映射是非常有必要的。一旦遇到問題，需要通過檢查生成的JavaScript代碼來找出原因。因此，所生成的JavaScript應(yīng)該與Python源代碼同構(gòu)。

利用已有的技術(shù)意味著源代碼必須是純Python的，而非一些更改了句法的變體。一種穩(wěn)健的實(shí)現(xiàn)做法是使用Python的原生解析器。同樣，在語義上也必須是存Python的，該需求會(huì)造成一些實(shí)際問題，需要引入編譯器指令以維持運(yùn)行時(shí)的效率。

需求三：

要保護(hù)企業(yè)在客戶端Python代碼上的投入，工具需要具有持續(xù)性。持續(xù)可用的客戶端Python編譯器應(yīng)具有良好的一致性和卓越的性能。如何維持這兩者間的平衡是編譯器設(shè)計(jì)中最關(guān)鍵的部分。

Python至今已連續(xù)三年成為***的計(jì)算機(jī)科學(xué)導(dǎo)論課程的教學(xué)語言，這一現(xiàn)狀足以保證受過培訓(xùn)的Python開發(fā)人員持續(xù)可用。Python已用于我們所能想到的所有后端計(jì)算領(lǐng)域上。如果瀏覽器端編程可以使用Python實(shí)現(xiàn)的話，那么所有的Python開發(fā)人員都可以進(jìn)行瀏覽器端編程。這些開發(fā)人員曾經(jīng)設(shè)計(jì)了長期運(yùn)行的大型系統(tǒng)，而非孤立的、短期運(yùn)行的前端腳本代碼段。

就生產(chǎn)率而言，Python在顯著增加產(chǎn)出的同時(shí)保持了程序運(yùn)行時(shí)的性能，這一點(diǎn)已得到那些從其它編程語言轉(zhuǎn)到Python的開發(fā)人員的公認(rèn)。對(duì)于那些關(guān)鍵運(yùn)算來說，比如數(shù)值處理和3D圖形處理，它們所使用的庫已經(jīng)被編譯成了本地機(jī)器碼，這也就是為什么Python能夠保持運(yùn)行時(shí)的性能。

***一點(diǎn)，對(duì)不斷發(fā)生變更的需求應(yīng)具有開放性，這意味要在各個(gè)層級(jí)上支持模塊化和靈活性。基于類的面向?qū)ο缶幊虨榇俗龀隽撕艽筘暙I(xiàn)，它提供了多繼承和復(fù)雜的包和模塊機(jī)制。此外，開發(fā)人員可以通過使用命名參數(shù)和默認(rèn)參數(shù)在不改變現(xiàn)有代碼的情況下改變調(diào)用簽名（call signature）。

對(duì)比一致性和性能：語言趨同發(fā)揮了作用

一些Python的構(gòu)件與JavaScript構(gòu)件非常近似，尤其是當(dāng)轉(zhuǎn)譯成***版本的JavaScrirpt時(shí)。兩個(gè)語言間明顯趨同。具體而言，越來越多的Python元素已經(jīng)融入JavaScript中，例如：for...of...、類（以有限的形式）、模塊、解析賦值（destructuring assignment）和參數(shù)展開（argument spreading）。因?yàn)镴avaScript虛擬機(jī)已經(jīng)對(duì)for...of...這類構(gòu)件做了高度優(yōu)化，有利于這類Python構(gòu)件轉(zhuǎn)化為最近似匹配的JavaScript構(gòu)件。這樣同構(gòu)轉(zhuǎn)化所生成的JavaScript代碼能受益于目標(biāo)語言的優(yōu)化機(jī)制，也易于閱讀和調(diào)試。

雖然Transcrypt中很多的調(diào)試是通過源映射（source map）在Python中逐步進(jìn)行的，而不是在JavaScript代碼中進(jìn)行的，但是工具不應(yīng)該隱匿底層的技術(shù)，而應(yīng)揭示底層技術(shù)，讓開發(fā)人員可以完全知道“事情的真相”。這一點(diǎn)更為可取，因?yàn)槿绻褂昧司幾g器指令，在Python源代碼的任何地方都可以插入原生的JavaScipt代碼。

下面是一個(gè)使用了多繼承的代碼段，展示了Python與Transcrpyt轉(zhuǎn)化的JavaScript代碼之間的同構(gòu)。原始的Python代碼是：

轉(zhuǎn)化后的JavaScript代碼是：

側(cè)重同構(gòu)轉(zhuǎn)化的局限性存在于細(xì)微之處，有時(shí)兩個(gè)語言之間的差異是難以處理的。例如，Python中可以使用“+”操作符連接列表，而如果在JavaScript中同構(gòu)地使用“+”操作符，不僅會(huì)導(dǎo)致列表被轉(zhuǎn)化為字符串，而且字符串會(huì)粘連在一起。當(dāng)然，a + b可以被轉(zhuǎn)換為__add__ (a, b)，，但是因?yàn)閍和b的類型在運(yùn)行時(shí)才能確定，這會(huì)導(dǎo)致即使對(duì)于1 + 1這樣簡單的事情，也會(huì)生成函數(shù)調(diào)用和動(dòng)態(tài)類型檢查代碼。再給出一個(gè)關(guān)于如何解釋“真值（truthyness）”的例子?？樟斜碓贘avaScript中的布爾值是True（或者true），而在Python中則是False。要在應(yīng)用中全局地處理這個(gè)問題，需要對(duì)每個(gè)if語句執(zhí)行一次轉(zhuǎn)換，因?yàn)樵赑ython構(gòu)件if a:中不能判定a是一個(gè)布爾型，還是列表等其它類型。因此 if a:必須轉(zhuǎn)換為if( __istrue__ (a))。如果在內(nèi)層循環(huán)如此使用，會(huì)再次導(dǎo)致性能不高。

在Transcrypt中，嵌入代碼中的編譯指令（即編譯指示）用于編譯本地控制這類構(gòu)件。這允許了使用標(biāo)準(zhǔn)數(shù)學(xué)符號(hào)編寫矩陣計(jì)算，例如

M4 = (M1 + M2) * M3，同時(shí)不會(huì)對(duì)perimeter = 2 * pi * radius這樣的語句生成任何額外的開銷。從語法上說，編譯指示僅是在編譯時(shí)執(zhí)行對(duì)__pragma__函數(shù)的調(diào)用，而非在運(yùn)行時(shí)。導(dǎo)入包含def __pragma__ (directive, parameters): pass的樁模塊（stub module），可允許該代碼無需修改即可在CPython上運(yùn)行。此外，編譯指示可以置于注釋中。在避免命名沖突的同時(shí)統(tǒng)一類型系統(tǒng)

Transcrypt統(tǒng)一了Python和JavaScript的類型系統(tǒng)，而非讓它們毗鄰而居并實(shí)時(shí)轉(zhuǎn)換。數(shù)據(jù)轉(zhuǎn)換需要花費(fèi)一些時(shí)間，還增大了目標(biāo)代碼的規(guī)模以及內(nèi)存的使用，進(jìn)而增加了垃圾回收的負(fù)擔(dān)，使得Python代碼和JavaScript庫間的交互難以處理。

因此，Transcrypt的決策是去擁抱JavaScipt世界，而非創(chuàng)建一個(gè)平行的世界。下面提供了一個(gè)使用了Plotly.js庫的簡單例子：

其中的編譯指示語句是可選的，它允許字典鍵值忽略引號(hào)，只是為了方便。除此之外，代碼看上去非常類似于相應(yīng)的JavaScript代碼。你可以注意一下代碼中是如何使用列表解析式的，這是在JavaScipt中依然缺乏的特性。開發(fā)人員不用關(guān)心Python字典的字面量（literal）是如何映射為JavaScript字面量對(duì)象的，他們可以在編寫Python代碼時(shí)使用Plotly.js的文檔。轉(zhuǎn)化并非是在幕后完成的。在任何情況下，Transcrypt字典都是一個(gè)JavaScript對(duì)象。

統(tǒng)一類型系統(tǒng)時(shí)會(huì)產(chǎn)生命名沖突。例如，Python和JavaScript字符串都具有一個(gè)split()方法，但是兩者在語義上有很大不同。還存在很多類似的沖突情況，Python和JavaScript仍在發(fā)展演化，未來還會(huì)有其它的沖突。

為了解決這個(gè)問題，Transcrpyt支持別名這一概念。當(dāng)在Python中使用<string>.split時(shí)，就會(huì)被翻譯成一個(gè)具有Python的split語義的JavaScript函數(shù)<string>.py_split。在原生JavaScript代碼中，split指代的是原生JavaScript的split方法?？梢詮腜ython調(diào)用JavaScript的原生split方法，這時(shí)會(huì)稱其為js_split方法。雖然在Transcrypt中對(duì)這一類方法預(yù)定義了可用的別名，但是開發(fā)人員可以自定義新的別名，或是取消已有別名的定義。這種方式可以解決所有統(tǒng)一類型系統(tǒng)所導(dǎo)致的命名沖突問題，無需付出運(yùn)行時(shí)代價(jià)，因?yàn)閯e名是在編譯時(shí)進(jìn)行的。

別名也允許從Python標(biāo)識(shí)符生成JavaScript標(biāo)識(shí)符。例如，在JavaScript中允許將$符號(hào)作為命名的一部分，而在Python中是不允許的。Transcrypt嚴(yán)格遵循Python的語法，使用原生CPython解析器做解析，語法與CPython相同。一部分JQuery代碼看上去如下：

因?yàn)門ranscrypt使用編譯而非解釋，為允許加入極簡化（minification）和涉及所有模塊的交付，必須在編譯前確定導(dǎo)入的庫。為此，Transcrypt還支持C風(fēng)格的條件編譯，這可以從下面的代碼片段中看到：

在Transcrypt運(yùn)行時(shí)中，對(duì)JavaScript 5和6的代碼之間的轉(zhuǎn)換使用了同一機(jī)制：

這種方式考慮了較新版本JavaScript中的優(yōu)化，并保持了向后兼容。在一些情況下，優(yōu)化的優(yōu)先級(jí)要高于同構(gòu)：

一些優(yōu)化是可選的，例如是否能激活調(diào)用緩存。這會(huì)導(dǎo)致直接重復(fù)調(diào)用繼承而來的方法，而非通過原型鏈（prototype chain）。

對(duì)比靜態(tài)類型與動(dòng)態(tài)類型：腳本語言正走向成熟

對(duì)靜態(tài)類型優(yōu)點(diǎn)的認(rèn)可正在復(fù)蘇，TypeScript就是一個(gè)很好的例子。與JavaScript不同，靜態(tài)類型語法是Python語言不可分割的一部分，Python原生解析器就支持靜態(tài)類型語法。但是類型檢查本身卻留給了第三方工具，***的就是mypy。這是Jukka Lehtosalo的一個(gè)項(xiàng)目，Python的創(chuàng)建者Guido van Rossum也是該項(xiàng)目的貢獻(xiàn)者。為實(shí)現(xiàn)在Transcrypt中高效地使用mypy，Transcrypt團(tuán)隊(duì)也為項(xiàng)目貢獻(xiàn)了一個(gè)輕量級(jí)API，無需經(jīng)由操作系統(tǒng)直接從另一個(gè)Python應(yīng)用激活mypy。雖然mypy依然在開發(fā)中，它已經(jīng)可以在編譯時(shí)捕獲為數(shù)不少的輸入錯(cuò)誤。靜態(tài)類型檢查是可選的，可以在本地通過插入標(biāo)準(zhǔn)類型注解來激活。一個(gè)使用注解的例子是mypy的in-porcess API：

正如上例所示，靜態(tài)類型可被用于任何適合的位置。在上面的例子中是用在run函數(shù)的簽名中，因?yàn)樗茿PI模塊的一部分，可以被另一個(gè)開發(fā)人員從外部看到。如果有人錯(cuò)誤解釋了API的參數(shù)類型或是返回類型，mypy將顯式地給出一個(gè)錯(cuò)誤消息，指向產(chǎn)生不匹配的文件和行數(shù)。

動(dòng)態(tài)類型這一概念依然處于Python和JavaScript這些語言的中心位置，因?yàn)樗试S靈活的數(shù)據(jù)結(jié)構(gòu)，并有助于降低執(zhí)行任務(wù)所需的代碼量。源代碼量是十分重要的，因?yàn)橐斫夂途S護(hù)源代碼，首先要通讀代碼。就此意義而言，實(shí)現(xiàn)同一功能，100KB的Python源代碼要優(yōu)于300KB的C++源代碼，還不存在讀取類型定義的困難，這些類型定義中可能會(huì)使用模塊、顯式類型檢查和轉(zhuǎn)化代碼、重載的構(gòu)造函數(shù)和方法、處理多態(tài)數(shù)據(jù)結(jié)構(gòu)和類型依賴的抽象基類。

對(duì)于由單個(gè)編程人員編寫的、源代碼在100KB以下的小腳本，動(dòng)態(tài)類型只具有優(yōu)點(diǎn)，因?yàn)橹恍枰浅Ｐ〉囊?guī)劃和設(shè)計(jì)，而且編程中所有事情也會(huì)有條不紊。但是當(dāng)應(yīng)用增大到無法由個(gè)人構(gòu)建而需要團(tuán)隊(duì)時(shí)，這種平衡就發(fā)生了改變。對(duì)于這樣的應(yīng)用，即以大約200KB以上源代碼為特征，編譯時(shí)類型檢查的缺失會(huì)導(dǎo)致如下后果：

1. 很多錯(cuò)誤只有在運(yùn)行時(shí)才能被捕獲，通常是在整個(gè)過程的晚期階段，修復(fù)這些問題需要付出高昂的代價(jià)，因?yàn)檫@些錯(cuò)誤影響了更多已編寫好的代碼。

2. 由于缺少類型信息，對(duì)模塊接口可做多種解釋。這意味著為了能夠正確使用API，在團(tuán)隊(duì)成員間所做的協(xié)商需要花費(fèi)更多的開發(fā)時(shí)間。

3. 尤其是在大型團(tuán)隊(duì)中工作時(shí)，動(dòng)態(tài)類型接口會(huì)導(dǎo)致不必要的模塊耦合。而良好定義的稀疏接口才是我們需要的東西。

即便是只有一個(gè)參數(shù)的接口，如果參數(shù)指向的是一個(gè)復(fù)雜的、動(dòng)態(tài)類型的對(duì)象結(jié)構(gòu)，該接口就無法保證穩(wěn)定的關(guān)注分離。雖然這類“4W”（Who did What，Why and When）編程模式雖然帶來了極大的靈活性，但同時(shí)也導(dǎo)致了設(shè)計(jì)的延后，影響到大量已有的代碼。

應(yīng)用“耦合與內(nèi)聚”范式。模塊內(nèi)部可以在設(shè)計(jì)決策上具有強(qiáng)耦合，但是模塊之間***是松耦合的，一個(gè)更改模塊內(nèi)部結(jié)構(gòu)的設(shè)計(jì)決策不應(yīng)該影響到其它的模塊。基于上述的原則，在動(dòng)態(tài)類型和靜態(tài)類型間做出選擇時(shí)可以參考如下的經(jīng)驗(yàn)法則：

1. 對(duì)于特定的模塊內(nèi)部，設(shè)計(jì)決策是允許耦合的。將模塊設(shè)計(jì)為內(nèi)聚實(shí)體，會(huì)導(dǎo)致更少的源代碼量，以及易于對(duì)各種實(shí)現(xiàn)進(jìn)行實(shí)驗(yàn)。對(duì)此，動(dòng)態(tài)類型是一種有效的方法，它可以用最小的設(shè)計(jì)時(shí)間開銷換取***的靈活性。

2. 在模塊間的邊界上，對(duì)于要交換什么信息，開發(fā)人員應(yīng)準(zhǔn)確地制定穩(wěn)定的“合約”。采用這種方法，開發(fā)人員可以并行工作，無需經(jīng)常性地進(jìn)行協(xié)商，他們的目標(biāo)是固定的，不會(huì)發(fā)生變化。靜態(tài)類型適合這些要求，對(duì)于哪些信息可以作為API的交互載體，它能給出正式的、經(jīng)機(jī)器驗(yàn)證的一致意見。

因此雖然當(dāng)前的靜態(tài)類型浪涌看上去像是一個(gè)回歸，但事實(shí)上并不是。動(dòng)態(tài)類型已取得了一席之地，并不會(huì)離開。反之也成立，C#這樣的傳統(tǒng)靜態(tài)類型語言也已吸收了動(dòng)態(tài)類型概念。但是考慮到使用JavaScript和Python等語言編寫的應(yīng)用的復(fù)雜性與日俱增，有效的模塊化、協(xié)作和單一驗(yàn)證策略愈發(fā)重要。腳本語言正走向成熟。

為什么客戶端要選擇Python而非JavaScript

由于Web編程的極大普及，JavaScript也正受到很多關(guān)注和投資。在客戶端和服務(wù)器使用同一語言有其明顯優(yōu)點(diǎn)。其中的一個(gè)優(yōu)點(diǎn)是，隨著應(yīng)用規(guī)模的增長，代碼可以從服務(wù)器端移動(dòng)到客戶端。

另一個(gè)優(yōu)點(diǎn)是概念上的一致性，這使得開發(fā)人員可以同時(shí)在前端和后端工作，無需經(jīng)常在技術(shù)間做轉(zhuǎn)換。Node.js這樣平臺(tái)廣受歡迎，正是由于人們希望降低應(yīng)用客戶端和服務(wù)器端在概念上的距離。但同時(shí)，這也將當(dāng)前Web客戶端編程的“放之四海皆準(zhǔn)”風(fēng)險(xiǎn)擴(kuò)展到服務(wù)器端。有人認(rèn)為JavaScript是一種足夠好的語言。近期的版本將開始支持基于類的面向?qū)ο螅愃朴谠谠蛢?nèi)膽上覆蓋了一層裝飾）、模塊和命名空間這樣的特性。隨著TypeScript的引入，使用嚴(yán)格類型成為可能，雖然將其集成到語言標(biāo)準(zhǔn)中仍需數(shù)年時(shí)間。

即使具有這些特性，JavaScript仍不會(huì)成為其它所有語言的終結(jié)者。對(duì)JavaScipt有些言過其實(shí)了（譯者注：原文借用了習(xí)語“駱駝是委員會(huì)設(shè)計(jì)的馬”，諷刺委員會(huì)喜歡虛張聲勢）。瀏覽器語言市場需要的是多樣性，事實(shí)上所有自由市場需要的都是多樣性。這意味著我們能夠?yàn)槭诸^的工作選擇正確的工具，即對(duì)釘子選用錘子，對(duì)螺絲選用螺絲刀。Python在設(shè)計(jì)上從一開始就是以清晰性、精確可讀性為準(zhǔn)則的。其價(jià)值不應(yīng)被低估。

在未來很長時(shí)間內(nèi)，大多數(shù)客戶端編程可能仍會(huì)選擇JavaScript。但是對(duì)于那些考慮替換語言的開發(fā)人員，對(duì)持續(xù)性有影響的因素正是語言的發(fā)展動(dòng)力，而非語言的具體實(shí)現(xiàn)。因此最重要的是使用哪種實(shí)現(xiàn)，而非選擇哪種語言。出于此考慮，Python無疑是一種有效的、安全的選擇。Python有很大的知名度，越來越多的瀏覽器在實(shí)現(xiàn)中考慮了Python，同時(shí)Python在保持性能的同時(shí)越來越接近CPython的黃金標(biāo)準(zhǔn)。