前端真的需要打包工具嗎？

01-06

最近使用webpack+jQuery+bootstrap+Vue+es6開發後台管理系統，真心覺得累，原因是總有解決不完的坑。
當初之所以用想用webpack是因為隨著系統應用的複雜，有些頁面實在是太多的功能聚在一起了。再加上是spa應用，首屏載入的資源特別的多。所以這經常出現白屏的情況。
其實我只想做到一下這些就可以了。
1、複雜頁面模塊化
2、瀏覽器緩存

3、合併css js
4、按需載入
上面的問題其實webpack都可以解決
但是有以下問題：
1、每次打包都要花費很多時間，加慢了開發進度
2、團隊能力不等造成很多問題維護成本
3、老版本框架不支持的問題
4、配置文件、查找bug、以及填不完坑問題
5、文件打包後出現的各種莫名問題
6、文件打包後體積問題

7、打包文件重複率問題
等等……
所以現在在想，所以瀏覽器引擎的優化我們真的需要webpack這些打包工具嗎？反正一個頁面載入幾十個js css文件也是沒有多大關係，唯一的缺點就是複雜頁面不好維護了。

是不是能力不夠？是不是能力不夠？是不是能力不夠？

能力不夠，對這些技術的拿捏和掌握不夠透徹，出了問題，就埋怨這些技術本身？

很多人還沒搞懂這些技術工具的主要目的和優缺點就盲目跟風地上了，你出了問題，解決不了或者解決地痛苦，當初你引進來的時候就沒有考慮到風險？

唉，圖樣圖森破

也順帶讓我聯想到某些人遇到某些問題就開始瞎猜並將其合理化的事，不了解和不想探究本質原因，對很多事情敷衍了事

單純從部署性能的角度來看，打包是暫行方案。rollup 和 http2 普及之後，打包按道理不會是強需求。

但是現在前端項目的代碼組織已經走上了編輯代碼和最終運行文件完全兩樣的路，所以就算不打包，一整套工具鏈肯定是少不了的。

前端終極狀態，目前看來應該會和傳統軟體趨同，代碼用於編輯，二進位/位元組碼用於分發，符號文件用於調試。在這種狀態下，打不打包，如何打包就不是個技術問題，而純粹是個生態和管理問題了。

我猜未來 npm 上會出現大量非開源模塊，這種時候應用怎麼組織呢？這大概會是個新課題。其實怎麼弄都行，看自己需要了。

題主的場景與其說打包工具增加複雜度，到不如說JQuery+Vue混搭增加複雜性。

打包工具如果使用三大框架，個人覺得是必須的，生產環境總不能在瀏覽器編譯吧？

JQuery+bootstrap的傳統項目隨意，不建議使用打包工具

PS，看到其他答案說到http2 。確實，如果http2普及打包工具確實就沒什麼必要了。

這樣思考的話如果瀏覽器對es6/7完全支持 babel也沒有必要(react的jsx和ng2的ts還是要編譯的)。長期來看隨著http2 es6/7 css屬性標準化(不再需要可惡的前綴)的普及打包工具會越來越雞肋。但是在此之前打包工具還是有存在的意義的(讓我想起了當年兼容ie6/7/8的日子)

用不用，一看能力，二看場景。

有能力你就可以利用新技術帶來開發效率，用戶體驗的提升。能力不夠那還是老老實實做。看看你們的技術棧，Webpack+jQuery+Bootstrap+Vue+ES6，有點混搭有沒有？其實是兩個技術棧：

jQuery+Bootstrap+Gulp：比較基礎的前端技術棧，也是上一代的前端技術棧。對前端要求的能力適中，適合做一些後端渲染的網站開發；

Webpack+Vue+Vue 周邊：都用Vue了，為什麼還要用 jQuery 和 Bootstrap。可以拋掉 jQuery，然後採用 Element 或者 iView - 一套高質量的UI組件庫這樣的前端框架。這是比較新的技術棧，對前端的要求能力其實也不高，但是要求有架構能力較強的中堅力量存在，才能駕馭好這些新技術。適合開發網頁應用，管理系統，體驗不錯的網站。

* + ES6：我們真的需要ES6嗎？加入 ES6，通常來講就意味著需要加入 Webpack 和 Babel，那麼多配置和插件，需要中堅力量去研究，並建立規範。新的語法或者語言最多算個甜頭，用得好可以提升效率和開發幸福感，用不好就是禍害。

多說一句，在目前的形式下，我認為前端對新技術盲從了，還沒學會走，就開始跑了。新技術棧正在替代老的技術棧，而且變得更難。每個前端團隊都需要打磨更好的工具，進行新的一輪全員培訓了！

好的項目推動講究思想先行，代碼後動。

作為webpack重度使用者，可以明確告訴你，題目裡面提到的問題都可以解決，而且方案不止一種。

講模塊化，webpack就是為模塊化而生的構建工具；論技術難度，聲明式的webpack配置文件難度不大吧；論編譯速度，你可以採用數組形式的配置文件，或者多個webpack實例，當然這塊確實需要開發者有比較好的webpack認識了。

論投入產出比，webpack比sea.js或者require.js高不止一個檔次。要是考慮到後期，構建工具的擴展或者ES語法升級，顯然用webpack是更合理的選擇。

最後，github上那麼多webpack boilerplate開箱即用，基本也不需要使用者做什麼配置工作。

順便說一句技術選型問題，用了vue沒必要用jquery,把bootstrap替換為ivew或者element都可以把你的開發工作量成倍減少。

類似webpack這樣打包工具的主要作用，是減少下載資源的HTTP請求數，同時還不用太操心那些文件要放到包里哪些不用。

上面提到的好處，主要體現在產品環境，在開發環境中，資源下載慢一點又何妨，只要開發體驗流暢就好。使用webpack的話，在開發模式下用Hot Module Reload，應該開發體驗也不錯。

應該說，只要場景不是太複雜，用webpack來做打包真的一點問題都沒有。

題主說到使用了jQuery和Vue，也許是歷史原因吧，但是我個人覺得都玩上Vue了就趕緊讓jQuery退休，實在不行兩者分開打包，不然遇到詭異事情真找不到合適的人問。

打不打包都看你本身的能力和項目的需要了。

很明顯，你說我就使用HTML+CSS+JS隨便實現一個什麼前端典型例子「輪播圖」…那你費這事幹什麼…直接寫啊！你&和&寫裡面都行！

但是如果稍微複雜一點的話，你就看看需不需要了。比如複雜一點的CSS，你選擇模塊的想法去實現一個項目，把每個塊的CSS都拆分開來寫，那最後你要合併成一個文件以方便link吧。這個時候就要打包工具了。比如「Animate.css」就這麼做的。

那這是基本的，現在有一些項目會用到CSS預處理工具的，比如LESS,SASS,STYLUS之類的。這類工具本身就是為了提升效率而出現的，因為復用性的關係。有些內容可以mixin，一些一樣的屬性不用寫多次，甚至一些計算相關的內容直接交給CSS不需要再使用JS。那麼這些東西到最後還是需要編譯成CSS吧。那其實這種情況也不需要用到打包工具，直接編譯文件夾就行了。比如「Syuanpi.css」就是這麼做的！

然後重點來了，如果你的項目里，用了EJS（HTML），用了Stylus（css），用了CoffeeScript（js），那這些奇行種瀏覽器可沒辦法直接讀懂，怎麼辦。你要把ejs編譯成html，你需要把stylus編譯成css等，或者東西寫多了，你還需要去壓縮css，壓縮js。那你是選擇一個文件夾一個文件夾去調用編譯器編譯，還是直接使用"grunt"或者"gulp"此類工具去實現「一鍵解決」的方法？

順便說下，gulp和grunt之類的算是構建工具，不算打包工具。

當然，我自己本身也不是很喜歡用webpack這個工具，因為「太強大」，也不需要那麼強大的工具。webpack用在spa之類比較多。因為它可以說是一個環境，而不是一個構建工具。一般的工作我覺得一個gulp加上需要的插件就能完成工作了。

但是如果諸如react, vue或者你自己實現了一個其他大型的項目，那怎麼可能不用webpack！

能力不夠就想辦法補能力，自己不思考，用框架和工具堆砌業務結果不僅代碼沒質量，自己能力也不會有任何提升。載入慢、坑多是因為你用了 jquery boostrap 以及各種不兼容第三方控制項導致，可通過 cdn，代碼壓縮，開啟 gzip ，非同步動態載入等方式一定程度上解決。請不要把鍋甩給 webpack 等打包工具，它的解決方式並不完美，但它是幫你解決問題的。

調試慢的問題請通過 webpack hmr 或者打開 watch 然後使用 livereload，webpack 使用 eval sourcemap 重編譯是非常快的。

樓下還有推薦 typescript 的，那東西是對項目穩定性有很大幫助，但是編譯實在慢的要死。

需要，而且jq和vue是個什麼搭配......

真的，不怎麼需要，這篇文章說了理由 https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8

用npm scripts配合簡單shell命令是一種更簡潔的方案，配置也很簡潔直觀，改也很好改。

"test": "mocha test -u bdd -R spec",
"pretest": "echo "about to run the test..."", "posttest": "echo "the test has been run!"",
"start": "node server.js",
"start:dev": "node server.js 4000"

相當多的項目打包只需要concat配合uglify足夠了。

需要下一題

不管怎麼說，ES 新標準也寫的舒服，CSS 預處理器和 postcss 也省不少事。其他嘛，看需要。大項目你沒點規劃怎麼行，小項目怎麼玩都玩不死。

之前網路慢的時候要求用多個文件，這樣可以同時下載。現在網速快了，要求減少網路請求次數，於是一個頁面一個js，一個css是比較好的選擇。而且最好壓縮下。css能夠合併的合併下。這些都需要工具來實現，而不是靠人工。

至於一個js還是分成多個js，自己去測試下載入速度就好了。

我覺得等全球主力瀏覽器全面原生支持import/export的時候，我們才能一定程度脫離打包工具。

Rails 社區從來沒有這個顧慮。

怎麼前端社區還在關心這些基本的東西？

內部系統，如果團隊成員能力不夠，沒必要上webpack，模塊化用seajs或者直接typescript來解決。內部系統，基本上也不存在頁面資源載入的性能問題，並且因為可以強制只支持chrome，使用http2等，來進一步簡化開發任務，合併資源，壓縮等已經不是必須。

選工具嘛，還是看場景，看需求和團隊能力

1、每次打包都要花費很多時間，加慢了開發進度：打包花費的時間應該是少數的幾次，正常肯定是在開發環境下實時調試開發的。

2、團隊能力不等造成很多問題維護成本：能力的問題，不是應該積極提升么？

3、老版本框架不支持的問題：老版本如果要引入的話，建議老闆重做=。=

4、配置文件、查找bug、以及填不完坑問題：通常這些坑一般就踩一次，個人感覺也還好吧。

5、文件打包後出現的各種莫名問題：這個目前還沒遇到過，一般都是在開發過程中就解決了。

6、文件打包後體積問題：迭代去除一些不必要的，替換一些輕量級的進行優化吧。

7、打包文件重複率問題：熟悉工具。

webpack新手，一起共勉~就醬~

首先回答問題，需要。

1.基於現狀我們還是得做壓縮合併等基礎的優化工作

2.如果想前端工程化開發，就更需要了。我自己就偏向工程化開發，所以喜歡打包工具。

題外話：jquery和vue搭配確實有待商榷，自己最開始也是使用這樣的搭配，但是越用越不對勁，因為這就說明沒有用上vue的一些優秀的功能。所以jquery是可以拋棄的，既然用了vue等框架，我們還得轉變我們寫js的思維方式。

是啊，很多工具其實是非必要的。

工具的真正作用是解決現實問題，你還不需要這種工具，只能代表你現在還沒遇到需要這種工具去解決的問題，並不能說明開發者的開發實力。

我以前對於版本管理器也很不解，認為有點累贅，但是在自己的開發路上成長遇到了很多坑，而版本管理正好解決了我的需求，因此我才會真正的開始使用版本管理。

像一下打包工具，事實上我沒有對這個有過依賴，因為我沒參與過大項目的團隊開發工作，在個人項目的部署上比較自由，沒什麼打包的必要。

當然，儘早接觸打包工具是好事，在小肉搏demo中使用不一定能提升你的效率，但是畢竟也算是多學會了一樣工具，而且項目組人數多起來的話，就會明白規範化比什麼都重要。

一開始的時候火車還沒有馬快。