如何評價阮一峰關於前端工具變化快的言論？

---

其實本答案並不是對工具變化快的直接評價，而是通過預言來間接給出評價：與我預言的即將發生的變革相比，阮老師所描述的變化是小巫見大巫。

我的這個預言或者說判斷，在2014年年中即已成形，但我一直憋到2015年年底才來回答——因為在一周前D2的夜場上，我在即興發言中終於憋不住拋出了我的預言：前端的構建部署即將發生革命性的變化——單獨的構建環節將逐漸弱化乃至消失，構建所包含的實質性內容即腳本、樣式等資源的編譯轉譯等將雲化和實時化。兩年後（到2018年時），不要說Grunt/Browserify，Gulp/Webpack等也均將退出主流。

具體來說，我預言明年（2016年）將出現包含JS模塊載入、包依賴自動處理、JS自動編譯這三項核心功能，並基於HTTP/2的前端資源雲服務（可理解為CDN的進化形態）。並且這類服務會在未來兩年里快速成長並帶動整個前端的大躍進。比如，通過ServiceWorker大幅提升瀏覽器緩存利用率，加上HTTP/2等協議級優化，Web應用的載入性能將獲得劃時代的提升；根據UA分發目標平台特定編譯版本和自動polyfill，Web應用的瀏覽器兼容性將獲得劃時代的提升；提供各種增值服務如方便部署安全特性，安全性監控、灰度部署、包的平穩升級、前端（精確到應用和所依賴的包）的錯誤監控和分析、前端性能監控和分析等，Web應用的質量將獲得劃時代的提升，開發效率也將是劃時代的提升……由此，前端工程師也會重新把很大一部分精力從構建部署相關的工程問題回歸到網站/應用的交互體驗本身。（不過應用框架和組件化相關的工程問題屆時是否能有比較一致的答案，現在看還很難說。）

以上就是我的預言，立此存照。

BTW，如果2016年9月前我預言的事情還沒開始發生，我會親自動手。 ^_^

---

構建工具鏈的變化，體現的是技術選型和工程能力的變化。

幾年來，大家已經逐漸習慣了「前端是需要構建過程的」這麼一件事，這是一個標誌，意味著前端逐漸從粗放走向精細化。

在整個構建過程中，主要有哪些環節呢？

資源的優化。比如圖片的合併，壓縮等等環節，也可能會為同一個圖片生成不同大小的多份。

轉譯。為了代碼的編寫體驗、可維護性等能力，我們可能會選用更高階的語言來編寫代碼，比如說使用ES6或者Coffee，TypeScript來編寫JS，使用LESS，SASS，Stylus來編寫CSS，然後在構建環節，把它們轉譯為可直接在瀏覽器中運行的代碼。將來也許這裡還會有asm.js那種類型的二進位構建。

文件的合併與重命名。這一步主要解決的請求數的降低，然而，這一步的水是最深的，因為有很多項目，尤其是大型的、應用型的，是需要一些權衡的，並不是把所有文件都合併起來就是最佳策略了，而且，要做得精確，就必須約束代碼的格式，掌控它們的依賴關係等等。完成之後，還需要把對應的引用地址修改掉，加上時間戳，防止緩存。

測試。這更加說明前端變得嚴謹了，之前的很山寨。

但是，我們需要注意到，以上這些東西，除了資源優化的環節，其他，都是跟技術選型相關的。也就是說，你首先必須根據自己的業務場景，選出合適的方案（包括框架和實施過程），然後，才可以根據方案，進一步選擇後三個環節的東西。

為什麼這些插件多？本質上，還是因為方案多。方案為什麼多？因為業務類型多，框架和庫也多啊，每來一種，就來一些圍繞它的構建插件，能不多嗎？

所以我覺得，插件基本上可以現學現用，重點還是之前的選型，選了陸路就去找車，選了水路就去找船，沒有車沒有船再自己造，不必被這麼多數量嚇到，你看街上那麼多美女，最後你還不是沒有女朋友~

---

推薦閱讀：