從命令列工具和 webpack 到 TypeScript，Flow 等其他工具，我們不妨來討論一下在 2018 年該如何使用 JavaScript。

去年，包括我在內的很多人都在談論 JavaScript 的乏力。事實上編寫 JavaScript 應用程式的方式並沒有真正減少，另外有很多命令列工具完成了大量繁重的工作，轉譯(transpiling)變得不那麼重要，並且 TypeScript 能夠減少型別錯誤的發生，這讓我們輕鬆了不少。

注：本部落格文章是我們的白皮書“JavaScript 的未來：2018 及遠方”的一部分，它提供了有關 JavaScript 的最新分析和預測。

譯者注：這裡將 transpiling 譯作“轉譯”，transpiling 是一個英文計算機術語。一般認為轉譯是一種特殊的編譯，當將一種原始碼語言編譯成另外一種原始碼語言時，就稱為轉譯。文中提到的 TypeScript 能夠編譯成 JavaScript。

命令列工具

大多數庫和框架都配備有一個命令列工具，通過輸入一個命令，可以為我們啟動一些框架專案，以快速建立我希望的東西。這通常包括一個啟動指令碼（有時用自動重新載入器），構建指令碼，測試結構等等。當我們建立新專案時，這些工具可以減輕我們大量冗餘檔案的編寫。讓我們來看看更多其他的一些命令列工具。

Webpack 配置

配置你的 webpack 構建過程並真正理解你在做什麼，可能是 2017 年更令人畏懼的學習曲線之一。幸運的是，他們的核心貢獻者之一 Sean Larkin 奔走在世界各地，為我們提供了很棒的演講和非常有趣和有用的教程。

現在許多框架不僅為您建立了 webpack 配置檔案，甚至將它們填充到您甚至可能不需要看的地步。

• npm run dev: 首要開發體驗
  • 用於 Vue 單檔案元件的 Webpack + vue-loader
  • 熱更新中的狀態保持
  • 編譯錯誤時的狀態保持
  • 儲存時使用 ESLint 檢查
  • 原始檔對映（Source Map）
• npm run build: 為生產環境準備好構建
  • 使用 UglifyJS v3 最小化 JavaScript
  • 使用 cssnano 提取所有元件中的 CSS 並最小化
  • 對靜態資源計算 Hash 使之在快取中長期有效，並自動為生產環境生成使用這些靜態資源 URL 的 index.html
  • 使用 npm run build –report 構建並生成含有流量分析的報告
• npm run unit: 使用 Jest  在 JSDOM 中執行單元測試，或者在 PhantomJS 中使用 Karma + Mocha + karma-webpack
  • 測試檔案支援 ES2015+
  • 簡單打樁
• npm run e2e: 使用 Nightwatch 進行端到端測試
  • 自動處理 Selenium 和 chromedriver 依賴
  • 自動生成 Selenium 伺服器
  • 在多個瀏覽器中並行地執行測試
  • 使用一個非常好的命令列工具：

preact-cli，從另一個方面支援著 Webpack 的功能。如果你需要自定義 webpack 配置，只需要建立 preact.config.js，它匯出一個函式來改變 webpack。大量的工具帶來了大量的便捷性，開發人員們也在相互幫助。

Babel：啟用還是關閉

弄明白了嗎？Babel 聽起來像巴比倫(Babylon)。我都快崩潰了。我並沒有試圖將 Babel 與 Babylon 聯絡在一起，但有人說過我們可能會放棄對轉譯(transpiling)的依賴。在過去幾年裡，Babel 一直是個大問題，因為我們想要 ECMAScript 提出的所有美好的特性，但又並不想等待瀏覽器跟上更新。隨著 ECMAScript 轉向年度小版本釋出，瀏覽器可能會跟上。剔除一些非常棒的 kangax 相容性圖表的 JavaScript 釋出是什麼樣的呢？

這些圖表的截圖不是很清晰，因為我想展示它們看起來是多麼的綠！更多有關詳細資訊，請單擊影象下方的連結以進一步檢視圖表。

在第一張圖中，左側的紅色塊是編譯器（例如es-6 shim，Closure等）和較舊的瀏覽器（例如Kong 4.14和IE 11）。右邊的五個紅色列是伺服器/編譯器PJS、JXA、Node 4、DUK 1.8和DUK 2.2。在較低的圖上，看起來像一隻狗並且亂七八糟的感嘆號的糟糕圖形的紅色區域是僅使用Node 6.5+具有綠色條紋的伺服器/執行時。左邊紅色方塊的構成是編譯器/polyfils和IE 11。更重要的是，看看那些綠的！在最流行的瀏覽器中，我們幾乎都是綠色的。2017年功能中的唯一紅色標記是Firefox 52 ESR for Shared Memory和Atomics。

從一些角度來看，這裡是來自維基百科的一些瀏覽器使用情況。

好的，關閉Babel可能會有點麻煩，因為當它落實之時，我們希望其能被儘可能多的使用者儘可能地訪問Babel。想想下我們可能能夠擺脫那個額外的步驟，在我們沒有使用轉譯器之時。

談談 TypeScript

如果我們在談 JavaScript，那就不得不談談 TypeScript。5 年前從微軟辦公室誕生的 TypeScript 發展到 2017 年，已經非常酷了。幾乎沒有什麼會議在談論“我們為什麼喜歡 TypeScript”，但它為開發帶來了新的體驗，自然受到人們喜歡。對於 TypeScript，不需要讚美，我們只是談談開發者在使用它的時候為什麼會感到輕鬆。

對於想在 JavaScript 中使用型別的人來說，TypeScript 在語法上是 JavaScript 的超集，為其帶來了靜態型別。如果你喜歡這種東西，就會覺得非常酷。當然，如果你看到了 JavaScript 狀態調查的最新結果，你會發現實際上很多人都喜歡。

我們看看 Brian Terlson 是怎麼說的：

作為 2014 年為 JavaScript 提議加入型別的人，我不認為型別會在較短時間內實現。從標準的角度來說，這是一個極其複雜的問題。對於TypeScript 使用者來說，採用 TypeScript 標準當然無可非議，不過也有其它一些J avaScript 超集支援型別，它們支援著一些相當重要的用法，比如 Closure Compiler 和 FLow。這些工具的行為各不相同，甚至不清楚它們是否存在一個共同的子集（我不認為有直觀的表現）。我不確定型別標準更像哪一個，我和其他人會繼續進行相關的調查研究，這可能是有意義的工作，但不要希望在短期內完成 – HashNode AMA with Brian Terlson

TypeScript 喜歡 Flow

在 2017 年，你大概看到了很多帖子在討論 TypeScript + Flow 的組合。Flow 是 JavaScript的靜態型別檢查器。 通過 Flow 你可以在圖表中看到 JavaScript 的狀態，這裡面的內容包含了你感興趣和不感興趣的。儘管很多人還沒有聽說過 Flow，但是他們應該會對一些狀態感興趣。如果人們在 2018 年學習了更多的 Flow，那他們就會發現 Minko Gechev 所做的有用的事：

TypeScript 和 Flow 消除了你的產品中大約 15% 的 bug！ 還覺得型別系統沒有用麼？ https://t.co/koG7dFCSgF

Angular 喜歡 TypeScript

你可能注意到在 Angular 文件中所有的程式碼例子就是由 TypeScript 寫的。曾經在某個時候，有一種建議，你應該選擇過一遍 JavaScript 或者 TypeScript 的手冊，不過，看起來 Angular 的心已經動搖了。檢視連線 Angular 到 JS 風格的圖表，我們會看到實際上有一小部分會被Angular 連線到 ES6（TypeScript: 3777, ES6: 3997）。我們靜待它在 2018 對 Angular 的影響。

有關如何為您的下一個應用程式選擇正確的 JavaScript 框架的一些專家建議，請參閱此白皮書。

毫無疑問，我們的 JavaScript 將在 2018 年快速發展。作為程式設計師，我們喜歡編寫和使用那些讓我們的生活更輕鬆的工具。不幸的是，這有時會導致更多的混亂和太多的選擇。值得慶幸的是，命令列工具正在幫助我們減輕一些煩瑣的工作，並且 TypeScript 已經滿足了那些對型別錯誤感到厭惡的開發者。

JavaScript 的未來

想要深入瞭解我們在 JavaScript 的發展方向？ 不妨檢視我們的最新文章“2018 年 JavaScript 的未來及遠方”。