[譯] 什麼將會替代 JavaScript 呢？

• 原文地址：What Replaces JavaScript
• 原文做者：Matthew MacDonald
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：cyz980908
• 校對者：江五渣,Chorer

什麼將會替代 JavaScript 呢？

JavaScript 正在蓬勃發展。但因爲 WebAssembly 的出現，它的衰落可能只是一個時間問題。

有些編程語言很受歡迎。而有些只是被開發人員被迫接受。對於許多程序員來講，JavaScript 就是後者中的一個例子，每一個前端開發人員都須要學習和理解這種語言，可是卻沒有人喜歡它。

十年前，JavaScript 尚未統治世界的跡象。其餘的平臺，像 Java，Flash 和 Silverlight 也依然在被咱們使用。以上三個平臺都須要運行在一個瀏覽器插件中，且三者都用一種不一樣的用戶界面替換了 HTML。這種方法使它們在功能特性方面遠遠領先於 JavaScript —— 例如，早在 \<video> 元素、CSS 動畫或 HTML canvas 以前，咱們就能使用它們添加視頻、動畫和繪圖。但這也意味着它們的衰落。當移動瀏覽爆炸式增加，HTML 轉向擁抱移動瀏覽器時，這些平臺也已過期。

諷刺的是，就在 JavaScript 征服世界的同時，一顆小小的種子被播下。它將在將來的某個時候，宣告 JavaScript 的終結。這顆種子就是一種叫 asm.js 的實驗技術。

可是介紹它以前，咱們仍是退一步來審視當下的形勢。

轉碼：目前的作法

自從咱們有了 JavaScript，開發人員就一直試圖避開它。一種早期的方法是使用插件將代碼從瀏覽器中取出。（該方法失敗。）另外一種想法是開發能夠轉換代碼的開發工具，將用另外一種更受歡迎的語言編寫的代碼轉換成 JavaScript。這樣，開發人員就能夠如願地讓代碼處處運行，同時又能避免弄髒雙手。

把一種語言轉換成另外一種語言的過程叫作轉碼，但這個過程並不是一路順風。高級語言有不一樣的特性、語法和習慣用法，你不能單純直接地映射到另外一個等價的結構上。就算你能夠，這也是有潛在危險的。若是社區中止開發你最喜歡的轉碼器怎麼辦？或者若是轉碼器引入了本身的 bug 怎麼辦？若是要插入 Angular，React 或 Vue 這樣的 JavaScript 框架怎麼辦？若是你在團隊中不使用相同的語言開發，你又將如何與團隊合做呢？

如同許多開發案例同樣，一個工具的好壞取決於它背後的社區。

現在，轉碼器已是再常見不過了，但它們的用途每每只有一種 —— 處理向後兼容性。

開發人員都是儘量使用最新的 JavaScript 版本，而後使用相似 Babel 之類的轉碼器將他們的代碼轉換成同等的（但不那麼優雅的）舊版本 JavaScript 代碼，這樣代碼就能夠兼容全部的運行環境。或者更好的是，他們使用 TypeScript（一種添加了強類型、泛型和不可爲空類型等特性的現代化 JavaScript）並將 TypeScript 轉換成 JavaScript。不管哪一種方式，你都是在 JavaScript 這片小花園裏打轉。

Asm.js：一塊墊腳石

一種新的可能性的曙光來自於 2013 年，Mozilla 的開發人員作的一個獨特實驗 —— asm.js。他們那時正在尋找一種在瀏覽器中運行高性能代碼的方法。但與插件不一樣的是，asm.js 並無試圖與瀏覽器爲鄰。相反，它的目標是直達 JavaScript 虛擬機。

從本質上講，asm.js 是一種簡潔、優化的 JavaScript 語法。它比普通的 JavaScript 運行得更快，由於它避開了語言中緩慢的動態部分。可是，意識到這一點的 web 瀏覽器也能夠應用其餘方法優化，從而大大提升性能。換句話說，asm.js 遵循了黃金法則 —— 不要破壞 web，同時還提供了將來改進的方法。Firefox 團隊藉助 asm.js 和一款叫作 Emscripten 的轉換工具，把用 C++ 構建的實時 3D 遊戲放到了 web 瀏覽器中，只須要 JavaScript 和一顆初心即可暢玩。

asm.js 最重要的部分是它迫使開發人員從新思考 JavaScript 的做用。Asm.js 代碼是 JavaScript 代碼，但這不意味着程序員應該手動編寫和操做 asm.js 代碼。相反，asm.js 代碼應該由自動化過程（一個轉碼器）構建，並直接提供給瀏覽器。JavaScript 是中間的媒介，而不是最終傳遞的信息。

WebAssembly：一項新的技術

儘管 asm.js 實驗產生了一些耀眼的演示，但它在很大程度上被工做的開發人員忽略了。對他們來講，這只是另外一項有趣的新興技術。但隨着 WebAssembly 的誕生，這一切都改變了。

WebAssembly 既是 asm.js 的接班人，同時又是一項大相徑庭的技術。它是一種緊湊的二進制代碼格式。與 asm.js 同樣，WebAssembly 代碼也被輸入到 JavaScript 執行環境中。它們倆具備相同的沙箱和相同的運行時環境。與 asm.js 同樣，WebAssembly 的編譯方式使得更進一步的效率提高成爲可能。可是如今的效率就已經比之前快多了了，瀏覽器能夠徹底跳過 JavaScript 解析階段。對於一個普通的邏輯位來講（例如，耗時的計算），WebAssembly 的速度遠遠快於常規的 JavaScript，幾乎與本機編譯的代碼同樣快。

若是你想知道 WASM 寫起來是什麼樣的，那麼你能夠想象一下你有這樣一個 C 函數：

int factorial(int n) {
  if (n == 0)
    return 1;
  else
    return n * factorial(n-1);
}
複製代碼

它將被編譯成以下所示的 WASM 代碼：

get_local 0
i64.eqz
if (result i64)
    i64.const 1
else
    get_local 0
    get_local 0
    i64.const 1
    i64.sub
    call 0
    i64.mul
end
複製代碼

當經過網絡發送時，WASM 代碼被進一步壓縮成二進制編碼。

WebAssembly 的定位是編譯器。你永遠不會手寫它。（可是，若是你想進行深刻的探索，你固然能夠去作。）

WebAssembly 首次出如今 2015 年。今天，桌面和移動設備上的四大瀏覽器徹底支持它（Chrome，Edge，Safari 和 Firefox）。它在 Internet Explorer 中不受支持，儘管將 WebAssembly 代碼轉換爲 asm.js 能夠實現向後兼容。（性能將會受到影響，拜託請讓 IE 消失吧！）

WebAssembly 和網站開發的將來

WebAssembly 開箱即用，爲開發人員提供了一種一般使用 C++ 編寫優化代碼例程的方法。這是個強大的功能，可是使用範圍有限。若是你須要提升複雜計算的性能，這將頗有用。（例如，fastq.bio 使用 WebAssembly 加快了他們的 DNA 測序計算。）若是你須要移植高性能遊戲或編寫在瀏覽器中運行的模擬器 ，那麼 WebAssembly 你值得擁有。若是這就是 WebAssembly 的所有功能，那就太沒意思了 —— 它也將不會有取代 JavaScript 的但願。WebAssembly 還爲其餘框架開發人員提供了一條小路，使得框架開發人員能夠將其平臺壓縮到 JavaScript 環境中。

事情在這裏發生了有趣的轉變。WebAssembly 不能是脫離 JavaScript 的，由於它被鎖定在 JavaScript 運行環境中。實際上，WebAssembly 至少須要與一些普通的 JavaScript 代碼一塊兒運行，由於它沒法直接訪問頁面。這意味着，若是不通過 JavaScript 層，它就沒法操縱 DOM 或接收事件。

這聽起來像是一個要突破原則的限制。可是，聰明的開發人員已經找到了在 WebAssembly 中偷偷搬運運行環境的方法。例如，Microsoft 的 Blazor 框架，下載一個小型 .NET 的運行環境做爲編譯後的 WASM 文件。這個運行環境處理 JavaScript 的互操做，並提供基本服務（如垃圾收集）和更高級的功能（佈局、路由和用戶界面小部件）。換句話說，Blazor 使用了一個存在於另外一個虛擬機中的虛擬機。這既能夠說是一個使人費解的悖論，也能夠說是一種建立在瀏覽器中運行的非 JavaScript 應用程序框架的聰明方法。

Blazor 並非惟一一個由 WebAssembly 支持的實驗。以 Pyodide 爲例，它的目標是將 Python 放到瀏覽器中，並提供用於數據分析的高級數學工具包。

這就是將來。WebAssembly 一開始只是爲了知足 C++、Rust 的需求，但很快就被用於建立一些更有野心的實驗。不久後，它將會帶來那些非 JavaScript 框架與基於 JavaScript 的標準框架（如 Angular、React 和 Vue）同臺競技的機會。

並且 WebAssembly 仍在迅速發展。它目前的實現是一個最小可行性的產品 —— 僅可以在一些重要的場景中發揮做用，而不是在 web 上開發的通用方法。隨着 WebAssembly 的逐步普及，這個現象將獲得改善。例如，若是像 Blazor 這樣的平臺流行起來，WebAssembly 可能會支持直接訪問 DOM。如今，瀏覽器製造商們已經在計劃添加垃圾回收和多線程的機制，有了 WebAssembly，運行環境這些細節他們也不須要本身實現。

若是你認爲這條 WebAssembly 的發展之路看起來漫長並且使人懷疑，那麼想一想 JavaScript 的例子吧。首先，咱們看到，若是有些事情 JavaScript 能夠作到，那麼它就會被完成。而後，咱們瞭解到，若是瀏覽器頻繁作某件事，那麼瀏覽器會讓它工做得更高效更好，等等。因此說，若是 WebAssembly 流行了，它將進入一個良性循環的發展過程，而且很容易超越 JavaScript 的固有優點。

人們常說，WebAssembly 不是用來替代 JavaScript 的。但這適用於以前的每個發生革命性改變的的平臺。JavaScript 不是用來取代瀏覽器嵌入 Java 的。Web 應用程序也不是爲了取代桌面應用程序而設計的。但一旦它們能夠，它們就會替代。

若是發現譯文存在錯誤或其餘須要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。

---

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源爲 掘金 上的英文分享文章。內容覆蓋 Android、iOS、前端、後端、區塊鏈、產品、設計、人工智能等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃、官方微博、知乎專欄。