Package、Library、Framework 的關係
要理解什麼是 Framework，我們需要從最基礎的概念開始。
什麼是 Package？
當我們寫程式寫久了，難免會開始使用別人的套件：
- 前端：npm 套件
- PHP 後端：Composer 套件
這些套件通常我們都稱為 Package。
什麼是 Library？
通常我們常用的 Package 大多是 Library 等級的。
以 jQuery 為例：
- jQuery 是一個 Library
- 它想解決的問題是：前端直接操作 DOM 的難度
- 因為原生 JavaScript 寫起來太繁瑣，所以有人開發 jQuery 來解決這個問題
什麼是 Framework？
按照 React 的說法：
- 如果只看 React 這個 Package → 它是 Library
- 如果看 React Ecosystem 整體 → 它是 Framework
如果用後端的 Laravel 來看會更極端：
- 原生 PHP 寫出來的東西可能很混亂
- 思考一下：用原生 PHP 寫出一個 Laravel 的難度
- 這就是「使用 Framework」vs「開發 Framework」的差別
一張表搞懂三者的差別
| Package | Library | Framework | |
|---|---|---|---|
| 規模 | 小，解決單一問題 | 中，解決某個領域的問題 | 大，提供完整解決方案 |
| 範例 | dayjs（日期處理）、uuid | jQuery、Lodash、Axios | Angular、Laravel、Django |
| 控制權 | 你呼叫它 | 你呼叫它 | 它呼叫你（IoC） |
| 學習成本 | 低，看 API 文件就好 | 中，需要理解設計哲學 | 高，需要遵守它的規則 |
| 自由度 | 高 | 高 | 低（但換來一致性） |
最後一行的「控制權」是很關鍵的差異。Package 跟 Library 都是「你去呼叫它」，但 Framework 是「它規定你怎麼寫，然後它在適當的時機呼叫你的 code」。這就是所謂的 IoC（Inversion of Control，控制反轉）。
層級關係圖
graph BT P["📦 Package<br/>單一功能模組<br/>e.g. dayjs, uuid"] --> L["📚 Library<br/>某領域的工具集<br/>e.g. jQuery, Lodash"] L --> F["🏗️ Framework<br/>完整解決方案<br/>e.g. Angular, Laravel"] F --> E["🌐 Ecosystem<br/>框架 + 社群套件 + 工具鏈<br/>e.g. React Ecosystem"]
主流框架快速比較
你可能會好奇，那市面上這些框架到底各自在做什麼？簡單整理一下：
| 框架 | 語言 | 特色 | 適合場景 |
|---|---|---|---|
| React + Next.js | JavaScript/TS | 生態系最大、彈性高 | SPA、SSR、大型應用 |
| Vue + Nuxt | JavaScript/TS | 學習曲線平滑、中文文件完善 | 中小型專案、快速原型 |
| Angular | TypeScript | 超嚴格、全家桶、企業級 | 大型企業應用 |
| Laravel | PHP | 優雅語法、功能齊全 | 後端 API、全端網站 |
| Django | Python | 自帶 Admin、ORM 強大 | 資料密集型應用 |
我自己的想法是，選框架不用太糾結。重點是你的團隊熟悉什麼、社群活不活躍、能不能找到人。技術本身的差異沒有你想像的那麼大。
什麼時候該用框架？什麼時候不該？
這是個很實際的問題。不是所有專案都需要框架。
適合用框架的情境：
- 多人協作的中大型專案（需要統一規範）
- 需要長期維護的產品（框架幫你管好結構）
- 功能複雜、互動多的 SPA 或後台系統
不一定需要框架的情境：
- 行銷活動頁（landing page），純靜態就好
- 個人部落格或文件站（用 SSG 工具如 Astro、Quartz 就夠）
- 快速驗證想法的 prototype（有時 vanilla JS 更快）
簡單來說，框架是為了解決大規模開發的混亂問題。如果你的專案不夠複雜，硬上框架反而是 over-engineering。
我的理解
如果你有辦法對一件事情提出 Total Solution，那你就是 Framework。
例如 Angular 會明確告訴你：「我可以把前端渲染這件事情完全搞定，還會逼著你照我的方式做。」這種就是 Framework。
但是界線真的太模糊了，太執著反而奇怪。