1. 程式人生 > >前端構建工具之爭——Webpack vs Gulp 誰會被拍死在沙灘上(轉載)

前端構建工具之爭——Webpack vs Gulp 誰會被拍死在沙灘上(轉載)

文章有點長,總共 1800 字,閱讀需要 18 分鐘。哈哈,沒耐心的直接戳我到高潮部分

理想的前端開發流程

在說構建工具之前得先說說咱期望的前端開發流程是怎樣的?

  • 寫業務邏輯程式碼(例如 es6,scss,pug 等)
  • 處理成瀏覽器認識的(js,css,html)
  • 瀏覽器自動重新整理看到效果

前端開發就是在不斷的 123..123..123.... 迴圈中進行的,上面的後兩步(也就是 2 和 3)應該是 自動化 的,前端開發者理應只需關注第 1 步——寫業務邏輯程式碼。

自動化的事情應該交由構建工具來做,時下流行的前端構建工具有 gulp 和 webpack(有人說 webpack 不算是構建工具,我覺得這沒什麼好爭的。橫看成嶺側成峰,我覺得從當前 webpack 所能做的事情來看,說它是構建工具絲毫不為過)。本文不會對

gulpwebpack 的概念和內容做深入解析,而是希望從巨集觀的角度研究他們的優勢短缺和適用場景,從而說清長期瀰漫在前端圈二者之間撲朔迷離的關係。

什麼是構建工具 構建工具是一段自動根據原始碼生成可使用檔案的程式,構建過程包括打包、編譯、壓縮、測試等一切需要對原始碼進行的相關處理。構建工具的目的是實現構建過程的自動化,使用它可以讓咱們避免機械重複的勞動(這怕是程式設計師最不能忍受的了),從而解放我們的雙手。 解放了雙手幹什麼 哇槽,愛幹什麼幹什麼。

Gulp 為何物

先來聽聽 Ta 的官網是怎麼說:

Gulp 致力於 自動化和優化 你的工作流,它是一個自動化你開發工作中 痛苦又耗時任務

的工具包。

想一想咱們日常的開發工作中痛苦又耗時任務有哪些呢?

  • 用 es6,typescript 編寫的指令碼檔案需要編譯成瀏覽器認識的 javascript
  • 用 scss,less 編寫的樣式檔案需要編譯成瀏覽器認識的 css
  • 檢查程式碼是否符合書寫規範,跑單元測試和整合測試
  • 開發環境如果有 sourcemaps 的話除錯起來就方便多了,修改完程式碼瀏覽器能自動重新整理立即看到效果就更好了
  • 生產環境部署程式碼需要壓縮合並靜態檔案,新增檔案指紋控制快取
  • blabla...更多的你自己想吧

Gulp 聲稱要幫咱們實現 自動化,那他是怎樣幫助咱們實現自動化的呢?這就不得不先提一嘴牛逼哄哄的 NodeJS

Node 背景小知識

Node 使前端 Jser 有了脫離瀏覽器工作的能力,要擱以前的話咱們寫的 js 要麼嵌到 html 頁面裡,然後用瀏覽器開啟 html 頁面才能執行js,要麼就是在瀏覽器開發者工具的 Console 面板裡編寫執行程式碼片段。總之沒了瀏覽器這個宿主,咱們的 js 就 run 不起來。Node 這貨突發奇想,把開發者工具的 Console 給摳下來了,從此 js 可以脫離瀏覽器直接在 node 裡執行。相當於 js 現在有了兩個宿主環境,一個是瀏覽器,一個是 node。當然了,Node 可不是開發者工具裡的 Console,那只是打個比方。它是基於Chrome V8 引擎實現的一個 JavaScript 執行環境,功能其實類似 Console 面板,但提供了大量實用的 API,感興趣的同學可前往 Node官網 詳細瞭解,英文吃力的騷年 戳這裡。Node 可以算是前端革命式的創新,隨 node 一起釋出的 node 包管理器 npm(node package manager) 也已經是全球最大的開源庫生態系統。node/npm 這對組合一出,前端生態迎來了大爆發,一時間為解決各種問題的 node 包層出不窮,遍地開花。gulp 就是披荊斬棘,一路過五關斬六將闖出來的一個小 node 包。

扯談完畢,接下來就來看看 gulp 是不是在裝逼,他到底能不能幫我們實現自動化。

作為一個 node 包,標準開啟方式當然是:

npm i -g gulp
 

然後呢,這裡以編譯 less 為例,首先安裝編譯 less 需要用到的 node 包:

npm i --save-dev gulp gulp-less
 

前面已經全域性安裝過 gulp 了,怎麼又本地安裝了一遍 前面的 -g 是全域性安裝,是為了執行你所編寫的 gulp 任務,即 gulp yourTask。而後面的 --save-dev 是本地安裝,是為了咱們編寫任務時使用 gulp 提供的 api,例如 gulp.src()gulp.task()gulp.dest() 等等。當然也是可以直接使用全域性安裝的 gulp 的 api 的,但是強烈不推薦,因為這樣涉及到 gulp 版本控制的問題,而且使用全域性 gulp 的 api 的話就會產生環境依賴(你假設環境已經全域性安裝了gulp,萬一沒裝呢,程式不就出錯了)。

接著在專案的根目錄下新建一個 gulpfile.js 檔案,這是 gulp 的預設配置檔案。

gulpfile.js 必須放在專案根目錄? 當然也可放在其他目錄,但這樣的話就得在啟動 gulp 任務時手動指定 gulp 配置檔案 gulp yourTask --gulpfile yourGulpfilePath,可能還需要全域性安裝 gulp-cli,所以除非有特殊需要,否則就放在專案根目錄就行了,這樣最簡單。 配置檔案的名字必須是 gulpfile.js 嗎? 不區分大小寫,取成 gULPFile.js 的話 gulp 也能認識,只要 toLowerCase 之後是 gulpfile 就行了,如果取其它名字那你就又得使用 --gulpfile 選項去指定了。

現在工程目錄結構已經成了下面的樣子:

構建前 gulp 工程目錄結構

接下來就是在 gulpfile.js 裡編寫 gulp task(gulp 把為每個痛苦又耗時任務編寫的處理方法稱為一個 task):

const gulp = require('gulp');
const less = require('gulp-less');