[譯] 願將來沒有 Webpack

• 原文地址：A Future Without Webpack
• 原文做者：FredKSchott
• 譯文出自：掘金翻譯計劃
• 本文永久連接：github.com/xitu/gold-m…
• 譯者：Badd
• 校對者：MarchYuanx, sunui

願將來沒有 Webpack

用 @pika/web 安裝的 npm 包能夠直接在瀏覽器中運行。這樣的話你還須要一個打包工具（bundler）嗎？

如今是 1941 年。你的名字是 Richard Hubbell。你在 CBS 旗下的一個試驗性的紐約電視演播室工做。你將要主持一場重大電視新聞廣播，這是世界上首批電視節目之一，你還有 15 分鐘就要上場了。你知道你一下子要幹嗎嗎？

在一我的們只知道收音機的世界裏，你會堅信你的認知。而你此刻的認知就是，你要把新聞稿讀出來。「Hubbell 主持的電視新聞節目幾乎都是照本宣科，偶爾把鏡頭切到一張地圖或者靜態圖片上。」還得過一陣子，人們才能在電視新聞上看到真實的視頻片斷。

做爲一名身處 2019 年的 JavaScript 開發者，我也有同感。咱們明明已經擁有了這個嶄新的 JavaScript 模塊系統（ESM），它能夠直接在 Web 環境中運行。可每次開發點什麼，咱們仍是得用打包工具處理一下。這到底爲何？

在過去的幾年裏，JavaScript 打包界的煊赫一時已經從只優化生產環境轉變到了逢開發必打包的程度。不論你喜歡與否，都很難否定打包工具給 Web 開發帶來了變態級別的複雜性，而 Web 開發明明是一個一向以源碼可見和輕鬆上手的精神爲榮的領域啊。

@pika/web 試圖將 Web 開發者從打包地獄中解救出來。都 2019 年了，你使用打包工具應該是由於你想要用，而不是由於你不得不用。

Credit: @stylishandy

咱們爲何要打包

JavaScript 打包不過是舊瓶裝新酒罷了。在過去（哈哈，大概 6 年前），在生產環境中將 JavaScript 文件壓縮併合並是屢見不鮮。這樣作可以提高網站的加載速度，並繞開 HTTP/1.1 的並行請求瓶頸。

原本這個優化有它更好沒有也行，怎麼後來就變成了開發過程當中絕對必須的步驟了呢？這就是最瘋狂的地方：大多數 Web 開發者歷來沒有特意要求過必須打包。相反，打包只是個反作用，咱們真正渴求的另有其物 —— npm。

npm —— 彼時表明着「Node.js 包管理工具」 —— 正在逐漸成爲有史以來最大的代碼註冊中心。前端開發者們但願能參與其中。惟一的問題在於，其 Node.js 風格的模塊系統（Common.js 或 CJS）不通過打包就不能在 Web 環境中運行。故此，Browserify、Webpack 以及其餘現代 Web 打包工具應運而生。

直觀感覺建立 React 應用：運行「Hello World」須要安裝超過 1300 個依賴包

複雜性斯德哥爾摩綜合徵

現在，想要開發 Web 項目，不用 Webpack 之類的打包工具基本是不可能了。就拿 Create React App（CRA）快捷方式舉例子，當你滿心但願能快速建立項目，卻發現須要先安裝超過 1300 個不一樣的依賴包，整個臃腫的 node_modules 文件夾足足有 200.9MB 大小，而你只是想運行個「Hello World」啊！

就像 Richard Hubbell 那樣，咱們都深陷於打包工具的泥沼之中，太容易忽略事物本能夠大相徑庭。咱們如今有這麼多優秀的現代 ESM 依賴包可使用（npm 上差很少有 50000 個！）。是什麼阻止咱們直接在 Web 環境上使用它們？

嗯，還真有那麼幾個緣由。😕本身寫 Web 原生的 ESM 模塊極其容易，並且確實有一些沒有依賴的 npm 包可以直接在 Web 環境中運行。但不幸的是 ，絕大多數 npm 包是行不通的。包自己會繼承其依賴的依賴，或者 npm 包經過包名導入依賴包這種特殊方式，這些都是緣由。

這就是爲什麼要創造 @pika/web。

@pika/web：無需打包的 Web 應用。

用 @pika/web 安裝的現代 npm 依賴能夠直接在瀏覽器中運行，即便這些依賴包自己也有它們本身的依賴包。一步搞定。它不是一個構建工具，也不是一個（傳統意義的）打包工具。@pika/web 是一種依賴包安裝時（install-time）工具，它極大地下降你對其餘工具的使用慾望，甚至可以徹底甩開 Webpack 或 Parcel 這類絆腳石。

npm install && npx @pika/web
✔ @pika/web installed web-native dependencies. [0.41s]
複製代碼

@pika/web 會查看 package.json 文件，覈對 "dependencies" 中全部導出了有效 ESM 模塊入口點的依賴，而後把它們安裝到本地的 web_modules 文件夾中。@pika/web 對全部的 ESM 包都有效，即便某些包帶有 ESM 混合 Common.js 的內部依賴。

安裝後的依賴包之因此可以在瀏覽器中運行，是由於 @pika/web 把每一個包打包成了一個單獨的、Web 環境可以支持的 ESM 模塊 .js 文件。例如：整個「preact」包對應着文件 web_modules/preact.js。這樣的機制能夠處理包內部可能出現的弊端，同時保留原始的包接口。

「哎你等會兒！」你可能會說，「這不就是換了個地方打包嗎？換湯不換藥啊！」

沒錯！@pika/web 利用內部打包機制來輸出 Web 原生支持的 npm 依賴，這也正是咱們不少人從一開始就使用打包工具的主要緣由！

有了 @pika/web，打包工具帶來的全部麻煩都被這個安裝時工具內部消化了。只要你不想，打包工具的配置代碼你一行都不用看。但話說回來，你固然能夠繼續使用你喜歡的其餘工具：提高開發體驗的（Babel、TypeScript），抑或優化產品的（Webpack、Rollup）。

這就是 @pika/web 的精神所在：打包，只因你想，而非必須。

附言：哦耶，我源碼可見又回來了！

性能

相較大多數打包工具的安裝方式，以 @pika/web 的方式（做爲單個 JavaScript 文件的方式）安裝每一個依賴，會帶給你極大的性能提高：依賴緩存。當你把全部依賴包打包成一個龐大的 vendor.js 文件，每當更新一個依賴，你就不得不迫使用戶從新下載整個 vendor.js。而若是用 @pika/web 的話，更新某個依賴包不會讓用戶從新緩存全部依賴。

@pika/web 幫你擺脫這些因打包工具致使的性能方面的拖累。多個打包文件中冗餘的相同代碼、無用或無關代碼致使的首屏加載緩慢、Webpack 生態升級帶來的坑和 Bug……全部這些文章和工具，都是人們使出渾身解數解決打包工具帶來的反作用的佐證。

要說明的是，不對源代碼進行打包處理，也不盡然老是十全十美的。針對在網絡傳輸過程當中的壓縮效果而言，體積大的 JavaScript 文件要好於體積小、粒度細的文件。而在 HTTP/2 協議下，瀏覽器要花更多的時間去解析導入多個小文件的請求，解析完才能將後續請求發出去。

這就須要你在性能、緩存效率和本身能接受的複雜度之間權衡。再說一遍，這是 @pika/web 的精神所在：打包，只因你想，而非必須。

Pika Web 開發策略

@pika/web 徹底改變了咱們作 Web 開發的方式。下面是咱們以前搭建 pika.dev 的過程，咱們向 2019 年的你強烈推薦，下一個 Web 應用就用 @pika/web 來幫助開發吧：

1. 開始新項目時，先別引入打包工具。用現代 ESM 語法寫代碼，用 @pika/web 安裝能夠直接在 Web 環境運行的 npm 依賴包。不須要什麼工具。
2. 你能夠隨時添加工具。若是須要強類型機制，那就添加 TypeScript；若是須要使用試驗性的 JavaScript 功能，那就添加 Babel；若是須要壓縮 JavaScript 代碼，那就添加 Terser。半年多過去了，pika.dev 在此階段的開發過程仍然順風順水。
3. 當你感受須要用而且有時間用打包工具了，能夠嘗試給項目添加一個簡單的打包工具。測試其性能如何。首屏加載是否迅速？那第二屏呢？若是都沒問題，安排！
4. 隨着開發進程的推動，不斷優化打包工具的配置。
5. 等你預算充足了，就聘請一位 Webpack 專家。恭喜恭喜！若是你有足夠資源能聘到一位 Webpack 專家，那你就算是正式地修成正果了。

想看些示例？有有有！

• 一個簡單的項目：[源代碼] [在線 Demo]
• 一個 Preact + HTM 的項目： [源代碼] [在線 Demo]
• Electron、Three.js…… 點擊此處查看所有示例

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

---

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