為什麼又造個輪子？
為什麼又要構建一個 JavaScript 構建工具呢？因為當前用於 Web 的構建工具比用戶期望的性能至少慢一個數量級。我希望這個項目可以作為一種“存在證明”，證明我們的 JavaScript 工具實際上能比現在快得多。
基準測試
我想到的用例是打包用於生產的大型代碼庫。這個流程包括壓縮代碼以減少網絡傳輸時間，以及生成源映射（對於調試生產中的錯誤是非常重要的）。理想情況下，構建工具還應該具備快速構建能力，而不必先預熱緩存。
我的主基準測試會將 three.js 庫複製 10 次並從頭開始構建單個包，過程中沒有任何緩存，從而模擬一個大型代碼庫。在這個基準測試中，esbuild 比我測試的其他 JavaScript 打包器（Webpack、Rollup、Parcel 和 FuseBox）快 10-100 倍。這個基準測試可以使用’make bench-three’來運行。
時間數據取三次運行中最好的一次，主要運行環境如下：
- 使用’–bundle --minify --sourcemap’來運行 esbuild。
- 使用’rollup-plugin-terser’插件，因為 rollup 自身不支持壓縮。
- Webpack 使用的是’–mode = production --devtool = sourcemap’。
- Parcel 使用默認選項。
- FuseBox 使用’useSingleBundle: true’配置。
- 絕對速度基於總行數（包括註釋和空白行），當前為 547,441。
- 測試是在配備 16GB RAM 的 6 核 2019 MacBook Pro 上完成的。
為什麼這麼快？
幾個原因：
- 它是用 Go 語言編寫的，該語言可以編譯為原生代碼；
- 解析，打印和源映射生成全部完全並行化；
- 無需昂貴的數據轉換，只需很少的幾步即可完成所有操作；
- 編寫代碼時處處注意速度表現，並儘量避免不必要的配置。
如何獲取？
分享到:
閱讀更多 InfoQ 的文章
關鍵字: JavaScript 測試 Go語言
