問題所在：你總在重複搭同樣的管路
想像你要做一個小網站，讓人能註冊、登入、發訊息。單看每一項都不嚇人。可在你寫下第一行有意思的程式碼之前，你會發現前面堆著一座又枯燥又瑣碎的活兒：接住網路請求、弄清楚對方要的是哪個頁面、核對密碼、跟資料庫打交道、再把正確的 HTML 發回去。地球上每一個應用程式都需要這同一套管路。
麻煩在於，這套管路不僅寫起來無聊——它還很容易出現細微的錯誤，而且到了下一個專案你又得從頭再寫一遍。這是大量被浪費的精力，也是大量在「跟你真正在乎的想法毫無關係」的程式碼裡埋下 bug 的機會。
框架是一套現成的鷹架
框架（framework）就是那條麵包。它是為一整類應用程式預先搭好的大骨架，所有枯燥的管路都已經替你寫好、測好、安排妥當。React 是在瀏覽器裡搭介面的框架；Django（Python）和 Rails（Ruby）則是搭網站伺服器端的框架。你挑一個，那又難又重複的 80% 一下子就「現成在那兒了」。
下面這一點能讓你瞬間「懂」框架，而它一開始幾乎讓所有人意外：是框架來呼叫你的程式碼——不是你去呼叫它。當你寫一個普通的小工具函式並使用它時，你是老闆：什麼時候執行由你說了算。換成框架，角色就反過來了。框架才是老闆。整場演出由它主導，到了恰當的時刻它會轉頭問你：「有使用者剛剛要看首頁——我該給他們顯示什麼？」你把答案遞給它，它再接手繼續跑。
# YOU just fill in the blank.
# The framework decides WHEN to call this.
def home_page(request):
return "Hello, world!"框架不會單獨前來：相依套件
框架很少獨自前來。為了幹好活，它會倚靠許多更小的、別人寫好的程式碼塊——一個處理日期的工具、一個跟資料庫對話的、一個安全核對密碼的。每一個這樣的東西都是一個相依套件（dependency）：你的專案「相依」它、但並不是你自己寫的程式碼。一個真實的應用程式輕輕鬆鬆就會倚靠上百個相依套件，其中大多數你永遠不會直接去看。
靠手工去下載並追蹤上百個零件簡直是噩夢，所以這件事你交給套件管理器（package manager）來做。你把想要的東西的名字列下來——在 JavaScript 裡這份清單寫在一個檔案裡，然後你執行一條像 `npm install` 這樣的命令——套件管理器就會把每一個都取回來，連同「它們」各自相依的東西一起，妥妥地塞進你的專案。一條命令，整條供應鏈就辦妥了。
npm install react
打包工具把這一切打包好去執行
現在你有了一種「太多」的煩惱。你的應用程式散落在你自己的檔案、外加上百個相依套件檔案裡，而它們沒法原樣直接送進瀏覽器（browser）——瀏覽器要一個一個去要上千個小檔案會慢得讓人難受，而且開發者寫的一些現代簡寫它還看不懂。這時候就輪到打包工具（bundler）出場了。
打包工具就像搬大家之前的打包服務。它走遍你所有的程式碼和相依套件，弄清楚到底哪些是真正用到的，把現代簡寫翻譯成瀏覽器看得懂的普通程式碼，再把一切壓進區區幾個整潔的檔案裡。這幾個最終檔案，就是被送進執行時（runtime）的東西——執行時就是瀏覽器內部那台真正執行你程式的引擎。
- 它從你的主檔案出發，順著每一個相依套件走，畫出一張「到底哪些真用到」的地圖。
- 它把現代的或特殊的寫法，翻譯成每個瀏覽器都能讀的普通程式碼。
- 它扔掉用不到的部分，再把剩下的壓小。
- 它輸出區區幾個最終檔案，隨時可以被瀏覽器載入並執行。
這裡的取捨是真實的，值得點明。打包工具會多出一道建置步驟（build step）：一個夾在「寫程式碼」和「看它跑起來」之間的環節，意味著要多設定一些工具，而且你每改一處都要等上一會兒。作為交換，你得到的是載入飛快的頁面、瀏覽器可靠看得懂的程式碼，以及自由使用那一大堆順手相依套件的權利。除了那種極小的頁面，這筆買賣幾乎總是划算的——而且現代框架通常已經替你把打包工具配好，讓你幾乎感覺不到這份代價。
把這一切串起來
於是一口氣把整幅圖景說完。你不會從零造一個網頁應用程式——你站在一個框架上，那是一套現成的鷹架，已經把無聊的 80% 處理好，需要你那份具體答案時才禮貌地來呼叫你的程式碼。這個框架倚靠著許多相依套件，而套件管理器用一條命令就替你把它們取回來、追蹤好。
最後，打包工具把這一切——你的程式碼加上每一個相依套件——收攏起來，打包成幾個整潔的檔案，讓瀏覽器裡的執行時能真正執行它，用多出的那一道建置步驟換來速度與便利。這些環節沒有一個是魔法。它們每一個的存在，都是為了讓你不必重寫同樣的管路，好讓你的精力流向它真正該去的地方：那個只有你才造得出來的部分。