零基礎要如何成爲前端工程師？

若是你是個毫無基礎又想要轉崗成前端工程師的迷惘初學者，你腦中浮現的第一個問題有八成會是這個。接下來你會作什麼？你大概會用：「如何成爲前端工程師」、「前端 入門」、「前端 轉崗」、「前端 非本科」等等的關鍵字來搜索，而後呢？
而後我但願你能搜索到我這一篇，讓我來好好告訴你。
基於上一篇（若是你還沒看過的話：跟着小明一塊兒搞懂技術名詞：MVC、SPA 與 SSR）的反應出乎意料的好，所以此次仍是由小明出馬，由一段虛構的故事慢慢帶你看前端工程師到底須要會哪些東西，故事看完了，你也差很少知道你到底該學什麼了。
這篇文章的目標是你沒什麼程序基礎也可以看得懂，比上篇的門檻再低一點。故事情節的發展順序不必定表明真實世界中這些技術出現的順序，順序的安排只是由於我以爲這樣子能幫助初學者更好理解這些技術到底在幹嗎。
好，讓咱們開始吧！
在好久好久之前…（真的好久）
那時候小明 12 歲，正在念小學六年級。在上電腦課玩着世紀帝國的時候（how do you turn this on?），老師忽然宣佈學校有舉辦班級網頁設計比賽，優勝者能夠得到十個好寶寶章。
身爲一個從小學二年級就開始用電腦的人，小明自認爲對電腦操做都很熟悉，心想網頁應該也不難，就決定接受這個挑戰。而且在回到家以後 ，上了奇摩知識+發問：

[急]請問要怎麼寫網頁？求解20點

底下熱心的網友們給了他兩個關鍵字：FrontPage 跟 Dreamweaver，而且跟他說寫網頁其實很簡單，這兩個軟件提供了不少現成的組件，你就想成是在打一份 word 文件就好，只是你能夠加上按鈕、表單等等只有網頁會出現的東西。你只要用拖拉的方式，就可以很輕易地寫出一個網頁來。
就以下圖所示，你能夠馬上看到你的網頁長什麼樣子：

圖片來源：https://googlesystem.blogspot...

圖片來源：https://yepdownload.com/macro...

雖然搞不太懂是怎樣一回事，但小明試用了一下這兩套軟件，發現寫個網站還真的很容易！就跟編輯文件同樣，你想要編輯什麼文字你就直接改就對了，要圖片的話也能夠很輕鬆的直接插入。
一直到小明長大後才知道，原來這種編輯模式就叫作「所見即所得」，你看到編輯器裏面長什麼樣子，實際上的網頁就會長成那個樣子（英文叫作 WYSIWYG，What You See Is What You Get）。
通過一番摸索以後，小明完成了班級網頁的雛形：

他才小六，不要太苛責他

「才一個下午我就能夠作成這樣，再給我三天，我應該能夠拿優勝吧」樂觀的小明自覺前途一片光明，想說今天也累了便先去洗洗睡了。
他不知道的是，坎坷的將來正在等著他。
與網頁,本人的初次見面
隔天放學回家，小明打開電腦想要繼續作班級網頁，但是卻發現 FrontPage 怎麼樣都打不開，重開機、從新安裝都沒有用，就只差重裝了。但是重裝會把即時通的歷史記錄所有都洗掉，母湯母湯，到時候小美傳給他的訊息就都不見了，這可不行。
一籌莫展的小明，看着昨天用 FrontPage 產生出來的 index.html，不知道哪來的靈感，對它點右鍵，選了「以記事本開啓」，看到了驚人的畫面：

這不是 Sublime，只是小明的記事本比較高級

「這是什麼碗糕！」整個畫面上，小明只看得懂中文，其餘的根本不知道在寫些什麼。
本來小明想把窗口關掉，但是卻轉念想說再看一眼好了，而這一看卻讓他發現了一些規律：

<xxx>彷佛都是成雙成對出現的，有<xxx>就會有</xxx>
style 看起來好像跟背景顏色之類的樣式有關
觀察到規律以後，小明心想那否則我來改改看，看會發生什麼事情好了。因而他就把 <li>通信錄</li> 複製了幾回而且改爲其餘文字，也把 body 那邊的 background 換成 #666666。
接着保存，不用記事本而是用網頁來打開，小明看到了下面的景象：

被小明手動更改過

「哇！竟然還真的改了！」
一直到往後小明去書店翻書才知道，原來網頁本人其實就是那個用記事本打開的文字檔，而 FrontPage 在作的事不過就是自動幫你產生這些文字而已。而那些成雙成對的<>咱們叫它標籤，不一樣標籤有不一樣的用途。
舉例來講，<li>就是 list item 的意思，而標籤裏面放的就是你的內容。至於 style 則是人如其名，負責管理全部跟樣式有關的操做，background 就是背景，color 就是文字顏色。
這些標籤跟內容咱們叫它 HTML（HyperText Markup Language），那些樣式叫作 CSS（Cascading Style Sheets），這就是構成網頁最基本的兩大元素。
知道網頁原來是由文字組成，不必定要用現成軟件才能夠寫出來以後，小明便拋棄了 FrontPage，跑到書店買了幾本網頁入門的書，下定決心從基礎學起。
不到半個月，他就已經能夠只靠文字編輯器來寫出整個網頁。
我也想要華麗酷炫的功能
得意洋洋的小明以爲同年齡必定沒有人像他這麼認真參加這個比賽，看來要拿到第一名是垂手可得了。如此天真的小明，有天碰巧看見隔壁班的小華在請教電腦老師一些網頁的問題，便湊上前去看。
不看還好，一看驚爲天人，兩千四百萬人都驚呆了。
首先呢，網頁上面有一個計數器，能夠顯示一共有多少訪客曾經造訪過這個問題。再來，你的鼠標附近會有一圈文字，鼠標移到哪裏文字就跑到哪裏，超級酷炫！還有網頁跑馬燈會不斷輪播班級的公告，就跟實體的跑馬燈效果同樣。
意氣風發的小明在那一刻啞口無言，深深以爲本身只是只井底之蛙，不知道外面的世界有多大。花了一些時間整了好本身的心態之後，小明鼓起勇氣問了隔壁班的小華：「欸欸，你那些效果怎麼用的，能夠教我嗎？」
『很簡單啦，你去搜尋：網頁開發百寶箱，那裏真的是百寶箱，要什麼有什麼！根本就是網頁設計師的哆拉 A 夢』
回到家之後小明照著作了，果然發現一片新天地，那裡充滿著各式各樣的酷炫功能跟效果，你只要把一段文字複製貼上到你的網頁就可以起做用。小明選了幾個本身以爲很帥的效果，改造了一下班網：

在此感謝一下網頁建置百寶箱，儘管如今已經連不上了 QQ

但是，若是隻是複製貼上的話，是贏不太小華的！必需要以這些特效爲基礎本身再定製化，纔可以殺出重圍，驚訝到學校的評審老師們。
秉持着這樣子的決心，小明仔細看了一下貼到網頁的那些文字，但願能發現一些端倪：

滑鼠移上去會動來動去的特效

雖然看不太懂是在作什麼，但小明心想：「這應該就是寫程序吧」，透過一些代碼來操控 HTML 上面的元素，產生出會震動的圖片的效果。
上網查了一些資料以後，小明才發現原來這個程序語言叫作 JavaScript，可以操縱網頁上面的東西，只要是看獲得的地方均可以用它來操做。因此理想上能作出任何你想獲得的功能。
以上面的圖片震動功能來講，就只是用 JavaScript 寫了如下代碼：

當鼠標移上圖片的時候
開始震動（震動原理：不斷改變它的位置）
當鼠標移開的時候，中止震動並恢復位置
知道原來能夠用 JavaScript 作出這麼酷炫的事情以後，沒有理由不把這個學好。因而小明就到書店找了幾本相關的書籍，從最基本的那些變量、迴圈、判斷式開始學，但願有朝一日可以寫出屬於本身的程序。

過了兩個禮拜，小明順利的實做出如下功能：

封鎖右鍵（原理：偵測到按下滑鼠右鍵時就刻意不作任何事）
顯示日曆（原理：靠代碼抓出如今時間並顯示出來）
顯示歡迎文字（原理：網站載入完成時就跳出一個視窗）

而憑藉着這些小明手寫出來的功能，順利得到了班網評審老師的一致讚揚，使得他拿到了班網比賽的第一名，把十個好寶寶章輕鬆歸入口袋。
本來就不謙虛的小明在奪冠以後變得更加狂妄，在即時通的狀態寫說：

哈！網頁不過就這樣嘛，就是 HTML 作內容，CSS 作樣式，JavaScript 加程式碼，只要會這三個就好，太簡單了吧！

是的，其實網頁一直到今天仍是如此，依舊是以這三者爲核心在發展。但是當原生的東西跟不上前端的演進的時候，咱們就必須先依賴一些第三方的工具，才能幫助咱們更有效率。

因而長大了之後

在拿到班網比賽冠軍以後，小明就發現本身對網頁設計真的頗有興趣，因而回家以後手裏拿的不再是 GBA，而是 Introduction to Algorithms，噢不對，是「第一次寫網頁就上手」、「100 個酷炫的 JavaScript 網頁特效」等等的相關書籍。
升上初中以後，他依舊努力不懈，靠着課餘時間進修網頁設計，對網頁三劍客（HTML、CSS 與 JavaScript）的掌握度也越來越高，自大的小明想說他應該已是世界第一等的水準了，是該出去外面的世界闖闖，就跟父母說他想要嘗試看看接案，拜託他們問問看朋友們有沒有適合的案子。
把案子交給一個初中生跟交給一個專業的工做室，雖然前者的確也有可能很厲害沒錯，但從公司的角度來看，仍是會傾向把項目交給後者，畢竟項目不僅僅只有「寫代碼」這件事情，還有開會討論、報價等等的流程。
但是皇天不負苦心人，得來全不費工夫，終於在初中二年級的時候，小明接到了人生中第一個案子。
這案子是一個公司官方網站的開發，圖片素材跟設計稿都由他們提供，小明只要負責把網頁寫出來就好，而且用 JavaScript 來實做一點特效。
小明雖然只是個 junior student，但自認爲是 super junior，花了兩個禮拜的時間就把版面切好，帶到公司去跟對方 demo。案主起初至關滿意，但卻問了一個小明從未想過的問題：

你有在其餘瀏覽器上面看過這個網站嗎？舊版 IE、FireFox 或是 Safari？

沒有，小明歷來沒有考慮到，他甚至連這世界上有這麼多瀏覽器都不太清楚。而案主當場把他自信滿滿的做品用其餘瀏覽器打開，第一個跑版、第二個跳出警告、第三個連畫面都跑不出來，直接白畫面顯示 JavaScript Error。
這件事情對小明的影響很深，很深。
從那一刻開始，他才知道世界比他想像中的大不少。在本身的電腦上能夠跑，不表明在別人的電腦上也能夠跑。寫網頁不僅是本身能夠看就夠了，也要保證其餘人看到的可以跟你同樣。

站在巨人的肩膀上

回到家針對不一樣瀏覽器測試以後，小明發現不少 CSS 跟代碼都必須對不一樣的瀏覽器作出調整才行，例如說在 safari 上面，可能要加上特別的 prefix 纔可以正常運行。
而 JavaScript 也是同樣，不一樣瀏覽器可能會有不一樣的 function name，要針對每一個瀏覽器寫出不一樣的代碼。
針對 CSS 的問題，小明發現只有幾個屬性要調整而已，很快就調好了，但是對 JavaScript，卻發現這是一件極爲麻煩的事情，有太多東西要加了，並且會把程式碼變得很是混亂。
正在焦頭爛額之際，有些已經在業界工做的網友跟他說：

你能夠用 jQuery 啊！

獲得了這個關鍵字以後，小明立馬去研究這究竟是個什麼樣的玩意兒。噢對了，若是你好奇他怎麼跟這些網友認識的話，他們是在程序設計俱樂部還有藍色小舖認識的。
研究了兩天以後，小明發現 jQuery 就是俗稱的 Library，但是在這領域不會翻做圖書館，而是翻做「函數庫」，意思就是它提供了不少現成的 function，你只要用就行了，不用知道他究竟是怎麼實際操做的。
這跟瀏覽器兼容性有什麼關注呢？關係可大了，之前你要寫 30 行代碼去兼容不一樣的瀏覽器，如今你只要用一行代碼，用 jQuery 提供的 function 就好，底層它都幫你作好兼容了。
除此以外，語法也變得比較簡潔，一些經常使用的功能它都幫你先寫好了。jQuery 的知名特徵就是 $ 這個符號，把一堆好用的 function 都放在這個裡面。
下圖是 jQuery 與原生 JavaScript（又稱爲 vanilla js）的比較，站在巨人的肩膀上之後，能夠少寫不少行程序代碼。

圖片來源：http://youmightnotneedjquery....

順利解決了瀏覽器兼容性的問題以後，案主也很開心的把這個案子結掉了。擁有了人生中第一筆收入的小明，今後之後開始了他的接案之路。
Don’t repeat yourself
隨着案子越接越多，小明有一個很是困擾的問題，那就是 CSS。你知我知獨眼龍也知，不少案主喜歡把需求改來改去，早上說網站主色是藍色的好，下午說仍是綠色吧，到了晚上又問說能不能改爲紅色試試看。
並且不僅顏色，可能網頁邊距啦，寬度啦，總之要一直改來改去的實在是很麻煩，並且不少時候還會改錯。
爲什麼會改錯呢？由於可能網頁背景、按鈕、文章背景都是用紅色作爲主色，因此最快的方法顯然是把全部的 red 都取代掉。但是有些顏色雖然也是紅色，但不是由於網頁主色是紅色，而是原本就應該是紅色，例如說錯誤提示的文字。這種就必須再改回來，否則會變得很奇怪。
所以，小明都是這樣改的：查找、替換，再把改錯的改回來：

簡易示範，使用 Recordit錄製，誠心推薦這款 App

在改來改去的過程當中，小明想起一句在這領域裏面頗有名的一句話：Don’t repeat yourself。不要一直作重複的事情，像如今這樣就很很差，永遠要屈就於這種很是不方便的流程。
有沒有可能把程序的概念引入到 CSS裏面去呢？例如說變量？這樣咱們就可以用變量來取代寫死的顏色，要改的話也很方便，只要改一個地方就好：

JavaScript 的變量+ CSS

在業界工做的前輩們聽到小明的想法以後，就跟他說了：

這不就是 CSS preprocessor 嗎？

CSS preprocessor，翻成中文就叫作 CSS 「預處理器」，簡單來講就是你能夠先寫一些不是 CSS 的語法，通過這個預處理器以後，就會變成符合標準的 CSS。
或是說得更白話一點，就是翻譯啦，你先寫中文，通過 Google 翻譯以後翻成日文，而後日本人就看得懂了。差異在於 Google 翻譯可能會翻的不精準，但是 CSS 預處理器可以翻的超級精準，保證是標準的 CSS。
有了預處理器以後，你就能夠把變量也應用到 CSS 上面，或甚至你要用迴圈或是函數也能夠！總之呢，有了預處理器以後，寫 CSS 跟寫程序的感受變得更類似了，下面是個簡單的範例：

圖片來源：https://sass-lang.com/guide

最經常使用的預處理器有幾個：SCSS/SASS、Less 跟 Stylus，語法都很相似，基本上挑一個學就夠了，要轉去其餘的也不難。有了預處理器以後，就可以更有效率地去寫 CSS。
但若是你不用預處理器，能夠寫網頁嗎？固然能夠！只是業主要你一直改顏色的時候你可能會很崩潰而已。
還記得以前提過須要針對不一樣瀏覽器去調整 CSS 嗎？有些必需要加 prefix 才能運做。這點用預處理器也可以很輕鬆地去解決，用一種叫作 mixin 的東西，你就想成是 function 就好：

圖片來源：https://sass-lang.com/guide

本來在每一個地方都要重複寫這些不一樣的屬性，如今把它包裝成 mixin，你只要 include 進來就好。
不過，小明有了一個疑問：

既然咱們都知道這個屬性要加 prefix，爲何不讓程序幫咱們自動加上就好？

對啊，爲什麼不？有個東西叫作 PostCSS，就是在作這件事情。（其實 PostCSS 包含了不少的 plugin，這邊提到的是其中一個叫作 Autoprefixer 的 plugin）
在這邊你要知道 PostCSS 跟 CSS preprocessor 的差異在哪，前者的 input 是 CSS，output 是加上了 prefix 以後的 CSS；後者的 input 是 SCSS（或其餘），output 是 CSS。你甚至能夠把二者合在一塊兒用：

純屬範例，實際上 border-radius 基本上不用加 prefix
合在一塊兒用的好處就是你在寫 SCSS 的時候，徹底不用管 prefix 這件事情，由於 PostCSS 都會幫你作好。
有了這兩項神兵利器之後，小明在寫 CSS 的時候就沒什麼太大的問題了，就算案主們的需求朝令夕改，也可以憑憑藉這些工具快速作出更動。並且長時間接案下來，已經累積了一套本身的程序代碼，可以迅速就搭出一個基本的頁面。
在不斷接案的過程當中，小明也就這樣漸漸長大，轉眼間已是個大一新生了。小明成長了，前端的世界也慢慢在成長，長成一個小明從未預料到的模樣。

像詩人依賴著月亮，像海豚依賴海洋

上了大學以後，小明開始挑戰接更大的案子，而更大的案子就意味著再也不只是那些美美的公司形象網站，而是開始往更複雜、更多功能的方向走，例如說購物網站或者是 CMS 系統等等。
身爲一個程式設計師，當你看到一個沒實做過的新功能時，第一件事情就是：上網去找有沒有人實做過。若是已經有人把輪子造出來了，大多數時候沒有必要本身從新作一個。
因而除了 jQuery 之外，小明開始用了其餘的 Library 來解決問題，直接把別人寫好的功能拿來用。但是用著用著，小明發現了一個問題，那就是引入 library 的機制。
如今的機制是怎樣呢？就是直接引入每個你要用的 library，而後直接用就好了：

用 script 標籤引入

看起來其實挺合理的，但會有幾個問題。
第一個，假如說 A.js 裏面定義了一個變量叫作：VERSION，而 B.js 裏面也定義了一個變量叫作 VERSION，那就會產生變數名稱衝突，兩個 library 互相干擾。
第二個，其實每一個 library 自己也有可能使用到其餘的 library，假設 A 用到了一個 library 叫作 popular，B 也用到了 popular，那咱們這邊其實就把 popular 引用了兩次（由於 A 跟 B 都用到了，因此在引入 A 跟 B 的時候各引入一次）。
總之呢，污染全局變量跟 library 之間的相依問題讓小明頭很痛，怎麼看都很不順眼。在理想上，小明以爲這些 library 的使用應該要像其餘程序語言那樣，例如說 Python：

簡易範例 Python 的 import

簡單幹淨利落，要用什麼 library，就用 import 把你要用的東西引入進來，也能夠在程序裏面把 library 用不一樣的別名引入，或者是隻引入特定的幾個 function。
雖然能這樣用必定很棒，但是 JavaScript 又不支持，怎麼辦呢？
咦？有沒有一種似曾相識的感受？
若是 CSS 能用變量就行了，必定會很棒，但是 CSS 又不支持…
若是原生不支持，解法很簡單嘛，咱們就僞裝有支持，以後透過工具把它轉成原生的程序代碼就行了。像 SCSS 就是這樣啊，反正轉換完以後是原生的 CSS，必定有支持。
因而呢，一個可讓 JavaScript 支持這種引入機制的 Library 誕生了：

圖片來源：http://browserify.org/

如今你能夠直接在代碼裡面寫：var A = require(‘libraryA’) 去引入一個 library，而不是用 <script/> 標籤去引入。而背後的原理就是靠着browserify 去幫你實做 require 這個函式，自動幫你處理好背後的相依性問題。
有了 require 的機制之後，在寫 JavaScript 的時候你就能夠分紅好幾個文件來寫，最後再透過 browserify 把代碼組裝起來：

利用 require 引入想用的模塊

最後透過 browserify，會產生一個 bundle.js，顧名思義，全部須要用到的東西都打包在裏面了，這就是你真正須要在 HTML 裡面引入的檔案。

這個要變、那個也要變，當我超級變變變？

雖然 browserify 成功解決了小明的問題，但是又有一個新的問題產生。截止目前爲止，咱們寫 SCSS，接著用指令把 SCSS 轉成 CSS。而後咱們在 JavaScript 裡面開心用着模塊，用 browserify 打包出 bundle.js。
儘管只是改一個小東西，就要打兩個不一樣的命令去作轉換，才能看到最後的結果。更別說要把這專案上線以前還要先對 CSS 以及 JavaScript 作混淆以及壓縮，把程序代碼變得更像亂碼一些。
這些流程以後只會隨著需求愈來愈煩瑣，該怎麼辦呢？可能過一年以後一個專案有十幾個命令要執行，有沒有什麼好用的工具可以處理這個呢？小明再次求助於認識的業界朋友們，最後得出了：Gulp 這個關鍵字。
Gulp 可以用代碼來管理你的 workflow，你就定義不少 task，說清楚每個 task 要作什麼事情，而後再去執行那個 task 就行了，以下圖所示：

圖片來源：https://gulpjs.com/

開頭定義一個 task 叫作 html，是來把 pug 檔案轉換成 html，第二個 task 叫作 css，用 less 轉換以後再 minify；第三個則是把 js 產生 sourcemap。只要你一打 gulp 這個指令，就會自動幫你執行上面三個 task。
有了 gulp 之後，當你拿到了一個陌生的專案，你直接去看 gulpfile.js 就能夠知道這個專案應該要怎麼開始跑或是怎麼打包了，每個 task 都清清楚楚寫在裡面。
之前咱們須要本身手動打好幾個指令，如今咱們用 gulp 轉換成一個個 task，只要一行指令就能夠又用 SCSS 轉換成 CSS 又用 browserify 打包成 bundle.js，十分方便。
如今的小明已經再也不是當年那個只會用 HTML、CSS 跟 JavaScript 寫着班網的小明瞭，而是手上握有 SCSS、PostCSS、browserify、Gulp、jQuery 等等工具的小明。有了這麼多工具輔助，在開發網頁的速度上面快了許多，由於每個工具的目標原本就是讓你變得更有效率，而不是拖累你。
就在此時，小明看到一個使人振奮的消息：新一代的 JavaScript 語法出來了（嚴格來說是 ECMAScript），叫作 ES6，在這新語法裡面多了小明很期待的一些新功能。

不支持怎麼辦？你知道的 ??

既然是新語法，想必舊的瀏覽器不會支持。小明一路跟著前端發展過來，也大概摸清了前端的套路。什麼是前端的套路？
當你想用瀏覽器不支援的東西時，你就開發個工具來轉換就對了
SCSS 如此，browserify 亦是如此。小明知道 ES6 推出時已是第三手的消息了，所以他深知必定已經有人作出這個工具了，上網搜尋了一下，Bingo！
這個工具就叫作 babel，它的官方網站簡單明瞭的說出了它的做用：

圖片來源：https://babeljs.io/

簡單來講就是你能夠寫新一代的 JavaScript（儘管瀏覽器還不支援），再透過 babel 把它 compile 成瀏覽器支持的語法。概念跟 CSS preprocesseor 有點像，但最大的差別在於 SCSS 的那些語法不是「下一代的 CSS」，因此瀏覽器之後也不會支持那些語法；而新一代的 JavaScript 只是「如今」還沒被瀏覽器支持，有朝一日必定會的。
等到那天到來，你就能夠把 babel 整個丟掉了，但是專案仍是同樣能夠正常運行（但那一天可能要好久就是了）。
用了 babel 以後，就能夠用一些又炫又潮的語法，只是你必需要多一層手續，用 babel 來 compile 才能在瀏覽器上面執行。不過沒關係，由於咱們有 gulp 了，因此只要在 gulp 裡面多增長一個 babel 的 task 就行了。
CSS 沒問題了，JavaScript 也有了模塊化以及新一代的語法，都已經這麼前衛了，難道還有什麼東西能夠再進化嗎？
靠北，還真的有。

你的資源，我全包了

前面提過了 browserify，讓你能夠用 require 把 JavaScript 引入進來使用。有人以爲單純這樣還不夠，提出了一個瘋狂的想法：

爲什麼只有 JavaScript 呢？爲什麼我不乾脆把全部東西都視爲資源？不僅要引入 JavaScript，我也能夠引入 CSS，甚至引入圖片！

這樣子一視同仁，把全部東西都視爲是資源的想法，就是 webpack 的核心理念。我不僅要 require(‘A.js’)，我還要 require(‘style.css’), require(‘bg.png’)只要是外來的資源，我所有都要引入！
webpack 用起來其實跟 browserify 很像，差異在於前者把更多東西都視爲是資源，因此寫出來的代碼會像這樣：

把一堆東西視爲資源

除此以外呢，webpack 也能夠透過一個個的 plugin，在打包的時候對這些資源作一些事情。什麼事呢？例如說用 babel-plugin 把 ES6 轉成 JavaScript！或者是用 scss-plugin 把 SCSS 程式碼轉成 CSS。
意思就是你在寫 code 的時候，你甚至能夠直接引入 style.scss，webpack 會自動幫你在引入時轉換成 CSS！聽起來很棒吧！
自從 webpack 嶄露頭角以後，browserify 就漸漸越來越少人用了，由於 webpack 能夠作的事情又更多一些，而 gulp 的不少 task 其實也能被 webpack 取代（例如說 compile）。
但要注意的是 webpack 只是一個 module bundler，不是像 gulp 那種 task manager，其實你能夠把二者配在一塊兒使用，就像咱們以前把 browserify 看成 gulp 的一個 task 同樣，你也能夠把 webpack 看成一個 task。
「呼，前端有了這麼多工具，應該很足夠了吧！」小明邊看著愈來愈多工具的專案邊感嘆著。
是的，工具差很少了，但是咱們前面一直專一的都是在：新一代的語法跟模塊化機制，徹底忽略了前端變複雜之後最困難的問題之一。

如何讓 UI 跟程序內部的狀態同步？

若是你如今有個 Todo List 的 App，假設你的程序裡面有一個 array 叫作 todo_list，你這個 array 長什麼樣子，你的介面就應該要長什麼樣子，這樣就叫作 UI 跟程式內部的狀態同步。
難嗎？乍看之下沒那麼難，咱們能夠寫出如下的程式碼，在操做 todo 的時候同時操做 UI 以及內部的狀態：

圖片來源：https://ithelp.ithome.com.tw/...

雖然在專案規模小的時候還行，但是若是你的專案超級無敵大，這就變成是一件很困難的事了，由於你要能永遠保證這二者是同步的。照咱們如今的方法，假如你有個 function 忘記更改狀態，那你就 GG 了，以後的狀態都不會再同步了。
Google 針對這個問題的解法是：那我自動讓這二者綁定好了，改變 state 就會改變 UI，而改變 UI 的話也會改變 state，這樣不就行了嘛！因而就有了 Angular 這套框架（我對 Angular 極度不熟，就只點到這了）。
而 Facebook 針對這個問題的解法很是很是很是直覺，真的很是直覺，是我認爲從概念上最好理解、最簡單的一個解法：

那就每次 state 改變的時候都從新渲染 UI 不就行了

你要刪除 todo，你直接刪除 state 的 todo，不用管網頁上的元件。你要新增也是同樣，徹底不用管畫面上的東西，由於只要 state 一改變，整個 UI 就會改變。以這個概念來實做的話，大概會變成這樣：

圖片來源：https://ithelp.ithome.com.tw/...

有沒有很簡單？有吧！
要如何讓 state 跟 UI 一致？寫代碼的人只要關注 state，每次都只改變 state，而後每改變一次就把整個 UI 按照如今的 state 從新畫出來，不就能確保二者徹底同樣了嗎？
聽起來頗有道理，那爲什麼之前的人沒想到呢？由於若是真的「每次都重畫」，其實會有效能問題，由於事實上你只要重畫一部分就好。但總之 React 解決了這個問題，讓你用起來像是所有重畫，實際上倒是隻重畫必要的部份。
在學 React 之前，只但願你記得 React 的這個核心概念就好：只改變 state 就好，UI 就會自動跟著改變。
把這複雜的前端問題解決之後，小明對前端的掌握度又更高了一層。

初出茅廬

故事說到這，小明大學也畢了業，兵也當完了，退伍的隔一天便很興奮地投了簡歷，過幾天后拿到了人生中首次的面試機會。想固然爾，他投的職缺是前端工程師。
整個面試的過程都很不錯，面試官很驚訝小明在這個年紀就可以對前端有這麼多的理解，並且該會的他都會了。在面試的尾聲，面試官問了這個一句：「這麼多的工具，你不會以爲很煩嗎？你都怎麼學會的？」
只見小明回道：
不會啊，出現問題不是就要解決嗎？我也沒特別學，就只是以爲用了這些工具可以解決個人問題罷了。
話說完，面試便結束了，而隔天下午小明就拿到了 offer。
「主管說你對程序的觀念很好，催促我必定要快點發 offer 給你。」，HR 是這麼跟他說的。

結語

爲什麼前端對新手來講這麼複雜，這麼多工具要學？由於他們根本不知道前面發生這麼多事情阿，他們沒有經歷過這一段演變，怎麼知道爲什麼要用這些工具？工具的出現是爲了把問題變得簡單，而不是變得更複雜。當你發現引入了工具卻讓你變得更沒效率，就應該好好思考你是否是根本不須要這個工具，而不是去怪工具很差用。文章看完了，若是我寫得還不錯的話，你應該會理解 HTML、CSS、JavaScript、SCSS（CSS preprocessor）、PostCSS、jQuery、Gulp、Babel、Webpack、React 這些東西在幹嗎，而這些就是現代一個前端工程師會須要的技能組（React 可換成 Angular 或 Vue）。小明身爲一個從之前就作前端作到如今的人，知道每個工具出來時要解決的問題。但身爲現今 2018 纔想要踏進前端的你，天然而然就會以爲前端怎麼這麼多工具這麼複雜。但其實不是的，若是有人能跟你講小明發生過什麼事，你應該就能對這些工具更瞭解。爲什麼、爲什麼、爲什麼！我一直再三強調你必定要經常問爲什麼，你必定要知道爲什麼這些工具會產生。當你知道背後的脈絡時，就知道工具實際上是在幫助你，而不是在阻礙你。就會知道這些工具的出現有其必要性，就可以更有個好理由去把這些工具給學好。只但願這篇能幫助到一些初學者們更理解本身如今爲何要學這些工具。若是有任何錯誤的話也麻煩不吝指證，感謝。