我們現在正處於 JavaScript 消亡的邊緣？
每 10 年 JavaScript 都會發生一次改朝換代式的變革。在我看來，JavaScript 當前正處於一次快速變革的開始，而這段時期未來可能會被稱爲 JavaScript 第三紀元。
本文最初發佈於 shawn swyx wang 博客，經原作者授權由 InfoQ 中文站翻譯並分享。
歷說從頭
JS 的第一紀元（從 1997 至 2007） 堪稱虎頭蛇尾。大家都知道 Brendan Eich 的故事，但是關於 ES4 是如何與諸如 Flash/Actionscript 之類的封閉生態系統艱難地進行激烈競爭的故事卻鮮爲人知。我推薦大家讀讀《JavaScript：20 年發展史》來了解 JS 起源的前前後後，我認爲這本書是一個非常合適的選擇, 因爲該書是由 JS 的主要作者 Brendan Eich 和 Allen Wirfs-Brock 聯手發佈的。
JS 的第二紀元（從 2009 至 2019） 是從關鍵的 2009 年開始的，這一年誕生了 npm，Node.js 和 ES5。隨着 Doug Crockford 在 《JavaScript 精粹》 一書中向我們展示了 JS 的精妙之後,JS 的使用者們創造出了一大堆的 JS 構建工具 和庫，並將 JS 的應用範圍擴展到了臺式機和新型智能手機。到了 2019 年，我們甚至看見，在手機端出現了諸如 Facebook 的 Hermes 之類的定製 JS 運行時系統，以及諸如 Svelte 3 之類的預編譯前端框架。
譯者注：
《JavaScript 精粹》，這本書的作者是 Doug Crockford，書中他主要從以 JS 的語法、對象、函數、繼承、數組、正則表達式、編碼格式以及一些優秀的功能等方面，向大家展示 JS 的精妙之處，同時也指出了 JS 的很多缺陷。
Hermes，是 Facebook 推出的一款運行在安卓系統中的 JS 引擎，該引擎對運行在安卓系統中的 React Native 應用做了性能優化，該引擎最大的特點是，會提前對代碼進行靜態優化和字節碼壓縮。
Svelte，是一個全新理念的前端框架，該框架最主要的 2 大特性是：
第一，將諸如代碼檢查、狀態管理、動畫等功能都做了封裝；
第二，構建時會將源碼直接轉換爲目標運行代碼，而不是在運行時再處理（這裏大家可以回想下在使用 webpack 構建的過程中，那個在運行時處理代碼的 runtimechunk.js）。
JS 的第三紀元
2020 年感覺像是一個新紀元的開始。如果說第一個紀元是關於一個語言的誕生，第二紀元是關於人們對這個語言的探索和擴展，那麼第三紀元則是與摒棄歷史觀念和工具層級摺疊相關。
注：作者早期提出過 層級摺疊 的觀點
在當前的 JS 生態裏，如果我們希望將編寫的代碼投入目標環境（例如瀏覽器環境）運行的話，大部分代碼都需要通過幾層工具的轉換，如 TS 編譯器、ESLint/JSLint、Less/Scss 、Babel、uglify 等，那麼作者認爲未來的趨勢是，這些處理層會被儘可能的摺疊。
首當其衝要摒棄的歷史觀念是：JS 生態需要依賴 CommonJS 模塊系統，這種觀念是不斷妥協的結果。ES Modules 作爲替代者已經伺機而動很久了，只是缺少一個一蹴而就的機會，主要的原因是，當前在使用中的工具雖然慢但是“已經夠用”，於是大家缺乏更換的動力。在前端，現代瀏覽器雖然已經具備了處理一些 ES Modules 功能的能力，但一些重要的細節依然沒有得到很好的解決。
譯者注：
由於這些重要的細節沒有解決，所以 V8 官方建議大家，在現代瀏覽器上使用 ES Modules 功能時，依然通過諸如 webpack、Rollup 之類的構建工具對源代碼進行構建。
Pika 的 Snowpack 項目希望通過提供一個外觀模式（facade）來加快 ES Modules 功能的提前應用，該模式會隨着 ES Modules 的完善而逐步消失。最後來點鼓舞人心的消息，IE11 從今年開始至 2029 年將逐步結束其緩慢的發展歷程。
另一個要摒棄的歷史觀念是：必須使用 JavaScript 構建 JavaScript 工具。 在熱路徑中，類型安全性和 性能提升（10 到 100 倍） 的潛力太大了，不容忽視。這種“只使用 JS 爲 JS 構建工具”的想法，隨着 TypeScript 幾乎完全接管了 JavaScript 而逐漸消失，同時最近嶄露頭角的 Deno 和 Relay 也進一步證明了，人們將會通過學習 Rust 來向 JS 核心工具庫做貢獻。Brandon Dail 預測這種轉變（工具的構建形式）將會在 2023 年完成。不過大部分使用中的非核心工具，由於其易用性相對性能更加重要，因此我們將依然會使用 JavaScript 和 TypeScript 進行編寫。以前我們考慮的是“功能內核，命令式 Shell”，而現在我們應該考慮的是“系統內核，腳本 Shell”。
注：上面的觀點也是有爭議的。Python 的解析器 PyPy 就表明這不是一個既定的結論。
層級也在以有趣的方式進行摺疊。Deno 採取了激進的方式，它編寫了一個全新的運行時，同時將諸如測試、格式化、代碼校驗和打包等一堆常用的任務工具摺疊到一個二進制文件中，針對 TypeScript 甚至直接包含了一個 標準庫。而 Rome 則採用了不同的方式，它還是基於 Node.js 將這些層摺疊了起來（據我所知，這些使用起來很簡單）。
10 年前，諸如 AWS、Azure、GCP 等公有云都還不存在，但是今天，它們已經是生活的一部分了。JavaScript 和雲之間的關係非常微妙，以至於我都很難清晰的表述出來。雲平臺的開發者不會直接使用 JS，但是 JS 卻又是他們最大的客戶。AWS Lambda 第一個推出對 JS 的支持，它的一個明顯變化是，摺疊了 IDE 層和雲服務層，移除了中間那個令人討厭的筆記本電腦。許多諸如 Glitch、Repl.it、Codesandbox、GitHub Codespaces、Stackblitz 的 雲服務發行者 都在利用 JS 來探索這個領域。與此同時，像 Netlify 和 Vercel 一樣，JAMstack 從 PoV 開始，合併了 CI/CD 層和 CDN 層，移除了其間令人厭煩的運行時服務。
即使在前端框架中，層級摺疊的發展同樣鼓舞人心。從動畫到狀態管理，Svelte 將所有的事情都摺疊到了編譯器裏。React 也在探索 元框架 和 客戶端與服務端集成 的方案，同時 Vue 正在致力於開發一個稱爲 Vite 的“無需打包”的開發服務項目。
總結：
在 JS 第三紀元中，其構建工具的發展將會是下面幾個方面：
- 更快
- ES Modules 優先
- 層級摺疊（事半功倍，而非事倍功半）
- 類型安全 / 類型安全檢查（以強類型語言爲核心進行構建，同時允許用戶零配置支持 TS）
- 安全 / 安全檢查（避免依賴注入攻擊，或者不嚴格的權限）
- 新的同構策略（充分的認識到，JS 應該首先在構建時運行，或者在到達客戶端之前在服務器端運行）
所有這些工作，最終都是促使開發體驗（更快的構建，行業標準的工具化）和用戶體驗（更小的構建包，更快的功能交付）變得更好。這是 JavaScript 從腳本編程語言到完整應用平臺的最終蛻變。
JavaScript 將死？
如果 Gary Bernhardt 的預言成真，那麼第三紀元將是 JavaScript 的最後一個發展紀元（Gary Bernhardt 給出的時間結點是 2035 年）。Web Assembly 總是在 JavaScript 的周圍若隱若現，甚至連 Brendan Eich 都改變了他的名言稱：“永遠押寶在 JS 和 WASM”，他最初認爲 JS 可能是“通用虛擬機”，但是曾經有人告訴我，現在 WASM 就是這個想法的最終實現。
如果真如上面所說，那麼我們現在正處於 JavaScript 消亡的邊緣。