昨天我們把網站拆成前端、後端、資料庫。今天要進第二幕，從前端開始。
講到前端，你可能聽過一大串名字：

JavaScript、TypeScript、React、Vue、Next.js、Angular、Tailwind⋯⋯

有些是程式語言，有些是框架，有些是函式庫。沒聽過也沒關係，今天就是要介紹它們。

在解釋之前，我先做一件事。

零、我先讓 AI 隨便做一個

我開了一個空資料夾，跟 Codex 說了一句話：

幫我做一個可以搜尋 K-POP 專輯配置的網站。

沒有額外的指定技術，沒有講之後要幹嘛。

【圖 1｜Codex 產出的第一版成果】

【圖 2｜他自動幫我內建一些現實真的存在的專輯】

【圖 3｜專輯細節彈窗也有，也可以收藏】

它做完了。而且老實說，做得不差（以我只打了一句話他就生成了這些的角度）。搜尋有即時過濾、可以按女團／男團／迷你專輯篩選、點擊專輯會跳出配置明細、可以收藏、可以複製配置清單。

這時候看 Cursor 瀏覽檔案的頁籤，裡面只有三個檔案：

index.html
styles.css
script.js

沒有 React，沒有 Next.js，什麼框架都沒有。

0.1 那三個檔案是什麼

這三個是瀏覽器原生看得懂的東西，常被叫做 「前端三件套」 ：

不管之後用什麼框架，網頁最後基本上都會變回這三樣，交給瀏覽器執行。

框架沒有取代 HTML、CSS、JavaScript，而是幫你管理元件、頁面、資料與程式結構，讓網站變大之後不至於越來越難維護。

0.2 為什麼 AI 預設會這樣做

這不是它偷懶。在那個情境下，這是很合理的選擇：

• 空資料夾裡，.html 雙擊就能開，不用安裝、不用設定
• 我沒說這是一次性的東西，還是要活三十天的專案
• 我也沒說要用什麼技術

這個選擇沒有錯。只是它解的，是我當下說出口的那個問題。

0.3 所以問題來了

如果三件套就能做成這樣，那一整排框架的名字，到底是幹嘛的？就是今天要回答的。順序是：先搞清楚那些名字各是什麼，再看我怎麼選，最後回頭對比。

一、把那些名字放回各自的層級

1.1 TypeScript 跟 JavaScript 是什麼關係

TypeScript 是建立在 JavaScript 之上的程式語言，可以把它理解成 JavaScript 加上型別系統等能力。很多 JavaScript 程式碼可以直接拿到 TypeScript 裡使用。

假設有一個欄位叫「發行年份」。純 JavaScript 不會阻止你把年份從數字改成 "2025"、"去年"，甚至 null。等到真的拿去排序或計算時，才可能發現資料長得不一樣。 TypeScript 會在你寫的當下就提醒你。

寫完之後，它會被轉成一般的 JavaScript 再交給瀏覽器。

為什麼這在 AI 開發特別有用？

因為 AI 產出的程式碼，你不一定每一行都讀得懂。但型別對不上，編輯器會直接畫紅線——等於多了一層不用你自己檢查的把關。

1.2 Library 和 Framework 差在哪

Library（函式庫） 像工具箱。你決定流程，需要功能時去拿。檔案放哪、程式怎麼組織，主導權仍在你。

Framework（框架） 像一間已經規劃好格局的房子。它通常會先替你決定一部分專案結構與慣例，例如程式怎麼拆、某些功能放哪裡、專案如何啟動。像 Next.js 這類框架，甚至連網址和頁面的對應方式都有現成規則。

現在那排名字可以歸位了：

⚠️ 這些界線沒有想像中硬。例如 Vue 官方就把自己稱為「漸進式框架」。這篇先用這些分類幫助理解，實際開發時，比起爭論它屬於哪一格，更重要的是它提供了哪些能力。

1.3 題外話：Next.js vs. NestJS

名字唸起來幾乎一樣，但搜尋資料或把建議貼給 AI 的時候，差一個字母就會走到完全不同的方向。

二、常見的選項

這裡不評分，它們都有大量產品在用。與其比「誰比較好」，我覺得更有用的問法是：它替你決定了多少事？

替你決定得少，自由但要自己組；決定得多，限制多但起步快。這個取捨，等一下會直接影響我的選擇。

三、怎麼選

3.1 「我只會 React」這個理由變弱了

以前選技術，很現實的考量是團隊會什麼 。學習成本、招募難度都是真的成本。一個人加 AI 的情況呢？這個理由的份量確實下降了。 對 React、Vue、Svelte 這類主流技術，現在的 Coding Agent 通常都能提供相當程度的協助。但有幾件事沒有消失，甚至因為 AI 才變得更重要 。

第一，AI 對這套技術的支援成熟不成熟。

熱門、文件完整、公開案例多的技術，AI 通常比較容易寫出一致、可用的東西。太新、版本變化快、或是很冷門的工具，就比較容易遇到過期的寫法，甚至根本不存在的用法。Day 2 說過：它的工作是產生合理的內容，不是保證正確。

第二，框架的約定會幫你管住 AI。

Day 5 我們花了一整節講「怎麼讓 AI 不要亂做決定」。框架其實幫你做掉一部分了——它規定頁面放這裡、共用的放那裡、檔案要叫什麼名字。這些規定不只約束你，也同樣約束 AI。

什麼都沒規定的話，AI 每次都選一個「它覺得合理」的放法。三十個檔案之後，那個專案就沒人看得懂了——包括 AI 自己。

框架的約定，等於幫你先寫好了一部分的合作規則。

第三，你自己看不看得懂。

AI 寫的東西你不用每一行都會寫，但你要看得出它在做什麼，不然沒辦法判斷它對不對。

AI 降低的是上手成本，不是判斷成本。

3.2 對照我的需求

四、回頭看那三個檔案

現在有了詞彙，可以回去看第零節那份成果，它其實真的做的不差。 以下這些，並不是「AI 寫錯了」，而是當初我們在提示詞內根本沒有提到。

這也可以驗證我之前說的，如果你有明確的想法，可以在提示詞中跟 AI 表達清楚。

4.1 每張專輯沒有自己的網址

點卡片開的是一個彈出視窗，網址從頭到尾都沒變。

所有專輯都擠在同一個網址裡，所以你很難把「某張專輯的配置」傳給朋友、使用者沒辦法加書籤，搜尋引擎也很難把每張專輯當成獨立的頁面。

當然，我也可以繼續在純 JavaScript 上把網址功能補起來。只是從這裡開始，網站長大需要的東西，我得一樣一樣自己組。

框架不是讓原本做不到的事突然做得到。它是替開始長大的專案，先把結構和慣例準備好。

4.2 資料和程式綁在一起

打開 script.js，第一行就是：

const albums = [
  {id:1, artist:"aespa", title:"Armageddon", ...},
  ...
];

這正是 Day 6 的 2.3 講過的那條線。每新增一張專輯，都得改程式碼、再重新部署。「維護資料」和「修改程式」變成同一件事。

4.3 收藏只存在這台裝置

收藏功能看起來做好了，但資料只存在這個瀏覽器裡。換一個瀏覽器，收藏就沒了。畫面上有收藏按鈕，不等於已經有收藏系統。

這三件事的共同點是：它們都是目前這個實作方式自然產生的限制——所有內容都塞在同一個頁面、資料直接寫在程式碼裡，也沒有真正的後端或帳號系統。

這三個問題，後面都會一個一個處理：網址會在第二幕後續的文章處理，資料和收藏要等第三幕接上後端和資料庫在做處理。

這個系列文會刻意一次只處理一件事，先讓你看到「不知道這些的時候會遇到什麼」。但如果你已經知道了，直接在專案的第一句 prompt 就寫進去，可以省掉很多來回修改的時間。

五、所以，我選 Next.js

對照需求表和第四節，理由其實已經很清楚了。

第一，要讓每張專輯有自己的網址， Next.js 有現成的路由方式，也很適合把頁面內容直接輸出給搜尋引擎讀取。

第二，它不只處理畫面。 一個網站開始長大之後，除了 UI，還會遇到網址怎麼對應頁面、資料怎麼取得，以及之後要不要在伺服器上處理一些事情。 Next.js 已經把這些常見能力整合在同一套框架裡。對現在一個人開發的我來說，與其一開始自己拼很多工具，我比較希望先有一套完整骨架，再隨需求慢慢往裡面加。

第三，約定明確。 呼應 3.1 的第二點。

第四，資源與案例非常多。 卡住的時候，不管搜尋還是問 AI，都蠻容易找到答案。

這不是唯一正解。 如果只是小型單頁應用、不太在意 SEO，也沒有 Server-side 需求，React + Vite 可能反而更直接。重點不是要選什麼，是你有沒有一組自己的判斷依據。當然，也可以先與 AI 進行多輪的溝通後，再決定。

至於資料庫要用什麼、登入怎麼做，今天都還不決定，等真的要存東西的時候再選，會選得準得多。

六、這次換種做法

前面已經決定要用 Next.js，接下來我就開一個新的專案資料夾，並告訴 Codex：

幫我用nextjs 做一個可以搜尋 kpop 專輯配置的網站

這和第零節的 Prompt 唯一的差別是我確定了這個專案要用 Next.js。 第一次我什麼都沒指定，AI 幫我選了最簡單能完成工作的工具。第二次我只多指定一件事：技術框架。

接下來就可以看看：只決定工具、不決定需求，究竟能改變多少？

【圖 4｜不只產生三個檔案了，網站啟動方式也不一樣】

【圖 5｜開啟新的終端機視窗，輸入npm run dev 可以啟動本地開發伺服器】

現在的 AI Agent 也可以執行這個指令、自動啟動瀏覽器查看網頁內容，自行修改。可以在提示詞中說明，他就會執行操作。

【圖 6｜新版的首頁外觀】

【圖 7｜一樣有專輯列表】

【圖 8｜一樣有專輯細節，但他不是用彈出視窗，而是從側邊展開】

你可能發現了，兩個版本很多地方不一樣：網站名字不同、配色不同、首頁的主視覺不同，連專輯詳情都從「彈出視窗」變成「側邊面板」。但我只在提示詞加了一件事：指定用 Next.js。
所以這些差異大部分不是 Next.js 造成的。我提示詞中沒講的東西，名字、風格、版面，它每次都會重新自由 發揮一次。前面有提到 AI 的輸出帶有機率性，其實就算同一句提示詞送兩次，結果也不會一樣。如果你希望固定下來，就得自己講清楚。

如果我們在提示詞中只換了框架，會發現那三個問題其實還在。因為框架只是把結構準備好，要做什麼，還是得你說，接下來的幾篇文章，就是要來解決這些問題。

結語與明日預告

今天從一份 AI 隨手做出來的成果開始，繞了一圈回到同一個地方。第一次，我沒做選擇，所以 AI 替我選了，而且選得合理。第二次，我知道問題在哪，所以把值得自己決定的部分拿了回來。

總結來說：

能跑，跟能長大，是兩件事。
框架不是讓原本做不到的事突然做得到，而是替開始長大的專案準備好結構。
AI 降低的是上手成本，不是判斷成本。

明天我們會把今天做出來的首頁進行排版的調整。

但在調整之前要先有語言：按鈕、卡片、導覽列、下拉選單⋯⋯這些東西都有名字。知道它們叫什麼，會直接影響你能不能把「這裡不太對」講清楚。

明天來認識這些元件的名字，以及一個你之後可能會很常打開的工具。

明天見