[[208959]]

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

1.從用戶的角度看，使用工具創建的與原生使用JavaScript開發的Web站點和應用在觀感、頁面加載時間、頁面啟動時間和持久速度等方面上應難以區分。

2.從開發人員的角度看，他們希望借助這些工具能夠無縫地訪問其他JavaScript庫，進行高效的調試。

3.從商業的角度看，應不斷有大量的開發人員愿意接受該工具的專業培訓，并在企業中使用，學習工具所花費的時間應能很好地轉化為生產力，并且使用該工具創建的應用夠滿足不斷變更的需求。

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

需求一：

Web站點和應用的觀感與所用的底層JavaScript庫有直接的關系。因此想要具有相同的觀感，站點或應用必須正確地使用同一軟件庫。

雖然快速的網絡連接可能會隱藏其中的差異，達到同樣的頁面加載時間，甚至對于在公共網絡或托管主機上運行近似大小代碼的移動設備也是如此。這使得在加載每個新頁面時，不可能去下載一個編譯器、虛擬機或較大的運行時。

只有當代碼是在服務器端靜態預編譯成JavaScript時，才有可能獲得與使用原生JavaScript同樣的頁面啟動時間。頁面中需要的代碼量越大，差別就會變得愈發明顯。

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

需求二：

要實現對所有JavaScript庫的無縫訪問，Python和JavaScript必須使用一致的數據格式、一致的調用模型和一致的對象模型。一致的對象模型要求JavaScript的基于原型的單繼承機制與Python的基于多繼承的機制融合在一起。應注意的是，JavaScript近期添加的關鍵字“class”對于彌合這個根本性的差異需求完全沒有影響。

要實現高效調試，必須在源代碼層面完成斷點設置和代碼單步執行這類工作。換句話說，源代碼映射是非常有必要的。一旦遇到問題，需要通過檢查生成的JavaScript代碼來找出原因。因此，所生成的JavaScript應該與Python源代碼同構。

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

需求三：

要保護企業在客戶端Python代碼上的投入，工具需要具有持續性。持續可用的客戶端Python編譯器應具有良好的一致性和卓越的性能。如何維持這兩者間的平衡是編譯器設計中最關鍵的部分。

Python至今已連續三年成為***的計算機科學導論課程的教學語言，這一現狀足以保證受過培訓的Python開發人員持續可用。Python已用于我們所能想到的所有后端計算領域上。如果瀏覽器端編程可以使用Python實現的話，那么所有的Python開發人員都可以進行瀏覽器端編程。這些開發人員曾經設計了長期運行的大型系統，而非孤立的、短期運行的前端腳本代碼段。

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

***一點，對不斷發生變更的需求應具有開放性，這意味要在各個層級上支持模塊化和靈活性?；陬惖拿嫦驅ο缶幊虨榇俗龀隽撕艽筘暙I，它提供了多繼承和復雜的包和模塊機制。此外，開發人員可以通過使用命名參數和默認參數在不改變現有代碼的情況下改變調用簽名（call signature）。

對比一致性和性能：語言趨同發揮了作用

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

雖然Transcrypt中很多的調試是通過源映射（source map）在Python中逐步進行的，而不是在JavaScript代碼中進行的，但是工具不應該隱匿底層的技術，而應揭示底層技術，讓開發人員可以完全知道“事情的真相”。這一點更為可取，因為如果使用了編譯器指令，在Python源代碼的任何地方都可以插入原生的JavaScipt代碼。

下面是一個使用了多繼承的代碼段，展示了Python與Transcrpyt轉化的JavaScript代碼之間的同構。原始的Python代碼是：

轉化后的JavaScript代碼是：

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

在Transcrypt中，嵌入代碼中的編譯指令（即編譯指示）用于編譯本地控制這類構件。這允許了使用標準數學符號編寫矩陣計算，例如

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

Transcrypt統一了Python和JavaScript的類型系統，而非讓它們毗鄰而居并實時轉換。數據轉換需要花費一些時間，還增大了目標代碼的規模以及內存的使用，進而增加了垃圾回收的負擔，使得Python代碼和JavaScript庫間的交互難以處理。

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

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

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

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

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

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

在Transcrypt運行時中，對JavaScript 5和6的代碼之間的轉換使用了同一機制：

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

一些優化是可選的，例如是否能激活調用緩存。這會導致直接重復調用繼承而來的方法，而非通過原型鏈（prototype chain）。

對比靜態類型與動態類型：腳本語言正走向成熟

對靜態類型優點的認可正在復蘇，TypeScript就是一個很好的例子。與JavaScript不同，靜態類型語法是Python語言不可分割的一部分，Python原生解析器就支持靜態類型語法。但是類型檢查本身卻留給了第三方工具，***的就是mypy。這是Jukka Lehtosalo的一個項目，Python的創建者Guido van Rossum也是該項目的貢獻者。為實現在Transcrypt中高效地使用mypy，Transcrypt團隊也為項目貢獻了一個輕量級API，無需經由操作系統直接從另一個Python應用激活mypy。雖然mypy依然在開發中，它已經可以在編譯時捕獲為數不少的輸入錯誤。靜態類型檢查是可選的，可以在本地通過插入標準類型注解來激活。一個使用注解的例子是mypy的in-porcess API：

正如上例所示，靜態類型可被用于任何適合的位置。在上面的例子中是用在run函數的簽名中，因為它是API模塊的一部分，可以被另一個開發人員從外部看到。如果有人錯誤解釋了API的參數類型或是返回類型，mypy將顯式地給出一個錯誤消息，指向產生不匹配的文件和行數。

動態類型這一概念依然處于Python和JavaScript這些語言的中心位置，因為它允許靈活的數據結構，并有助于降低執行任務所需的代碼量。源代碼量是十分重要的，因為要理解和維護源代碼，首先要通讀代碼。就此意義而言，實現同一功能，100KB的Python源代碼要優于300KB的C++源代碼，還不存在讀取類型定義的困難，這些類型定義中可能會使用模塊、顯式類型檢查和轉化代碼、重載的構造函數和方法、處理多態數據結構和類型依賴的抽象基類。

對于由單個編程人員編寫的、源代碼在100KB以下的小腳本，動態類型只具有優點，因為只需要非常小的規劃和設計，而且編程中所有事情也會有條不紊。但是當應用增大到無法由個人構建而需要團隊時，這種平衡就發生了改變。對于這樣的應用，即以大約200KB以上源代碼為特征，編譯時類型檢查的缺失會導致如下后果：

1. 很多錯誤只有在運行時才能被捕獲，通常是在整個過程的晚期階段，修復這些問題需要付出高昂的代價，因為這些錯誤影響了更多已編寫好的代碼。

2. 由于缺少類型信息，對模塊接口可做多種解釋。這意味著為了能夠正確使用API，在團隊成員間所做的協商需要花費更多的開發時間。

3. 尤其是在大型團隊中工作時，動態類型接口會導致不必要的模塊耦合。而良好定義的稀疏接口才是我們需要的東西。

即便是只有一個參數的接口，如果參數指向的是一個復雜的、動態類型的對象結構，該接口就無法保證穩定的關注分離。雖然這類“4W”（Who did What，Why and When）編程模式雖然帶來了極大的靈活性，但同時也導致了設計的延后，影響到大量已有的代碼。

應用“耦合與內聚”范式。模塊內部可以在設計決策上具有強耦合，但是模塊之間***是松耦合的，一個更改模塊內部結構的設計決策不應該影響到其它的模塊?；谏鲜龅脑瓌t，在動態類型和靜態類型間做出選擇時可以參考如下的經驗法則：

1. 對于特定的模塊內部，設計決策是允許耦合的。將模塊設計為內聚實體，會導致更少的源代碼量，以及易于對各種實現進行實驗。對此，動態類型是一種有效的方法，它可以用最小的設計時間開銷換取***的靈活性。

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

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

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

由于Web編程的極大普及，JavaScript也正受到很多關注和投資。在客戶端和服務器使用同一語言有其明顯優點。其中的一個優點是，隨著應用規模的增長，代碼可以從服務器端移動到客戶端。

另一個優點是概念上的一致性，這使得開發人員可以同時在前端和后端工作，無需經常在技術間做轉換。Node.js這樣平臺廣受歡迎，正是由于人們希望降低應用客戶端和服務器端在概念上的距離。但同時，這也將當前Web客戶端編程的“放之四海皆準”風險擴展到服務器端。有人認為JavaScript是一種足夠好的語言。近期的版本將開始支持基于類的面向對象（類似于在原型內膽上覆蓋了一層裝飾）、模塊和命名空間這樣的特性。隨著TypeScript的引入，使用嚴格類型成為可能，雖然將其集成到語言標準中仍需數年時間。

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

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