重點摘要
我的兩套醫療系統用 Next.js + React,但你正在看的這個作品集網站,是刻意用 Astro + 純 CSS 做的,沒有用任何前端框架。這不是因為我不會 React,而是因為這兩種東西要解的問題不一樣。這篇講這個選擇背後的判斷 —— 一個關於「用對工具、不過度工程」的例子。
先分清楚兩種網站
前端工具的選擇,先取決於你在做「網站」還是「應用程式」:
- 內容型網站:作品集、部落格、文件站。以「呈現內容」為主,互動少。使用者主要是讀。
- 互動型應用:診所系統、儀表板、可即時操作的工具。以「操作狀態」為主,一堆按鈕、表單、即時更新。
這是兩種不同的需求。用同一套工具硬做兩者,總有一邊不合身。
為什麼醫療 App 我選 Next.js / React
ClinCalc、ExClinCalc 是重互動的:身體地圖點選、即時判讀、多步驟表單、角色化的儀表板、狀態隨操作即時變化。這種「畫面要跟著使用者操作不斷更新」的場景,正是 React 這類框架的主場 —— 它讓你用狀態驅動畫面,不用手動去改一堆 DOM。
所以那裡選 React 不是趕流行,是需求真的需要。工具跟問題對得上。
為什麼這個作品集網站我選 Astro + 純 CSS
作品集網站幾乎全是靜態內容:文章、案例、關於頁。互動只有深淺色切換、圖片放大、手機選單 —— 這些用幾行原生 JavaScript 就夠,不需要一整套框架。
如果我硬用 React 做這個網站,會付出不必要的代價:
- 送一堆 JavaScript 到瀏覽器,只為了顯示本來就靜態的文字。
- 讀者的裝置要下載、解析、執行框架,才看得到一段本來 HTML 就能直接顯示的內容。
Astro 的做法相反:預設輸出純靜態 HTML,幾乎不送 JavaScript(這叫 島嶼架構)。結果就是:
- 打開快:瀏覽器拿到就是現成的 HTML,不用等 JS 跑完。
- SEO 好:搜尋引擎直接讀得到內容。
- 託管便宜:純靜態檔,放邊緣節點,月成本 $0。
至於為什麼純 CSS 不用 Tailwind:對這個規模的網站,我用一套自己的設計 tokens(一組 CSS 變數)就能保持全站一致、又完全掌控,還少一層建置複雜度。工具越少,越好維護。
判斷準則:什麼時候該用重框架
我心裡的簡單分界:
| 情況 | 傾向 |
|---|---|
| 內容為主、互動少(部落格 / 作品集 / 文件) | Astro / 靜態,甚至純 HTML |
| 少量互動點綴 | 靜態 + 幾行原生 JS,或 Astro 島嶼 |
| 狀態複雜、畫面隨操作即時變 | React / Next 這類框架 |
| 需要離線、桌面整合 | Electron(Kaizei 就是) |
關鍵問句不是「哪個框架最強」,而是「這個東西的互動複雜到需要框架來管狀態嗎?」 不需要的話,加框架只是增加重量和維護成本。
誠實說:這個選擇的代價
不偏袒地講,Astro + 純 CSS 也有代價:
- 重互動功能會比較費工:如果哪天這個網站要加複雜的即時互動,原生 JS 會比 React 難維護 —— 那時就該考慮在需要的那塊引入島嶼式的框架元件。
- 純 CSS 要自律:沒有框架幫你約束,設計 tokens 和命名要自己維持紀律,不然容易亂。
- 團隊習慣:如果是一個習慣 React 的團隊,強上 Astro 反而增加溝通成本。
對「一個人維護、內容為主」的作品集,這些代價都很小,好處很明顯。但我不會假裝它是萬用解 —— 選型本來就是看場景。
一個 meta 的結尾
你現在讀這篇文章的頁面,就是這個選擇的成品:打開很快、沒有一堆載入中的轉圈、深淺色切換即時。會用重工具,和知道什麼時候不用重工具,是兩種不同的能力 —— 後者我覺得更重要。
延伸閱讀
- 被問到「你的系統架構長怎樣」,我會怎麼講 ── 醫療 App 那邊的架構選擇
- CI/CD 白話拆解 ── 這個 Astro 網站怎麼自動建置上線