編按：本文綜合整理自 Andros Fenollosa 的原文〈Why I don’t recommend Tailwind CSS〉、Hacker News 留言討論、Tailwind Labs 官方 v4.0 公告，以及 State of CSS 與 npm 下載統計資料，並加入 Siami 編輯部觀點與分析。
事件背景
西班牙工程師 Andros Fenollosa（Andros.dev 站長、書作者）8 月 2 日在個人部落格發表長文〈Why I don’t recommend Tailwind CSS〉，直指這款在 React 圈被當作預設解的 utility-first CSS 框架，有七個他無法忽視的問題。文章同步衝上 Hacker News 第四名，得到 81 分、74 則留言。
在 HN 留言區，這篇文章的聲量呈現罕見的光譜：挺 Tailwind 派、傳統語意 CSS 派、原生 CSS 派三方正面交鋒。值得注意的背景是——2025 年初 Tailwind v4.0 發表，主打 CSS-first 設定、5 倍編譯速度、引擎重寫；Adam Wathan 自己在 2026 年 1 月也公開表示，營收因 AI 寫 Tailwind 程式碼不查文件而掉了 80%，公司裁員 75%。一邊是開發者採用率創新高，一邊是商業模式受 AI 衝擊，這篇批評文正落在這個矛盾最尖銳的時點。
原文七大質疑重點
作者用 8 個 H2 章節拆解自己的疑慮，下面濃縮成 7 大要點。
1. 要背幾十個 class 才能上手
Tailwind 有上千個 utility class，即使搜尋引擎與編輯器自動補完很強，仍有一個需要內化的下限。剛開始開發時，多數人會開著瀏覽器分頁 + 搜尋框並用，進展緩慢。一旦混入自訂 class 名稱，複雜度再往上疊。
2. 結構與樣式不再分離
不用 @apply 把 class 群組起來的話，HTML 會被幾十個 utility 撐爆，違反「HTML 管結構、CSS 管樣式」這條前 CSS-in-JS 時代的鐵律。可讀性變差，無法重用。
3. class 命名不夠一致
items-center（flex align-items）justify-center（flex justify-content）text-center（text-align）place-content-center（grid place-content）
四個都是「center」，但指向完全不同的概念。為什麼不叫 flex-align-items-center、flex-justify-content-center、text-align-center、grid-place-items-center？還有 border 給 1px、border-2 給 2px 的不對稱，都是「小摩擦但會累積」。
4. 設計系統沒有想像中嚴格
w-[347px]、text-[#1a2b3c]、p-[5.5rem]——任意值（arbitrary values）讓你可以逃脫 Tailwind 預設的間距與色階。同一個專案用 sky-400 跟 blue-400 沒人會擋你。一致性最後還是得靠紀律，不是靠框架。
5. 不是學 CSS 的好入口
沒 CSS 底子的人用 Tailwind，會產生「我會 CSS」的錯覺。pt-4 最後還是要在腦中翻譯成 padding-top: 1rem——你對抽象熟悉，不是對 CSS 熟悉。作者對學生與同事的建議是：先學 CSS，再用 Tailwind。
6. 難讀、且 HTML 對優先順序「說謊」
比較同一顆按鈕的 vanilla CSS 跟 Tailwind：
/* Vanilla CSS */
.button {
padding: var(--gap-s) var(--gap-m);
background: var(--color-indigo);
color: white;
font-weight: 700;
border-radius: var(--gap-s);
&:hover, &:focus { background: var(--color-indigo-hover); }
}
/* Tailwind + @apply */
.button {
@apply py-2 px-4 bg-indigo-500 text-white font-semibold
rounded-lg hover:bg-indigo-700 focus:bg-indigo-700;
}bg-indigo-500 是什麼顏色？rounded-lg 多圓？bg-indigo-700 比 bg-indigo-500 深嗎？第一段自解釋，第二段得查文件。
更關鍵的是——<p class="text-red-500 text-green-500"> 會顯示紅色，因為 Tailwind 在產出 CSS 時控制了順序，HTML 裡的 class 順序騙了你。class="mt-4 mt-0" 也不會照 HTML 順序套用。要嘛 !important，要嘛避免衝突——這就是所謂的 leaky abstraction（漏抽象）：表面說簡單，實際逼你懂底層。
7. 用 DevTools debug 不舒服
class 太多的元件在 inspector 裡要一直捲動看誰蓋誰；原生 CSS 至少能一眼看出有哪些規則、套用順序、錯在哪。編輯器外掛只解決「寫入」端，瀏覽器端那碗 class 湯還在。
Adam Wathan 自己承認
@apply「basically only exists to trick people」，並說如果重來一次他不會放進去——你用來恢復可讀性的工具，本身違反框架哲學。
🚨 為什麼這件事重要
這篇文章登上 HN 高位不是因為「又一篇罵 Tailwind」，而是因為它把框架哲學的內在矛盾點名得很精準：
- 7 個質疑中 3 個是純生產力問題（要背 class、debug 麻煩、不一致），但 4 個是架構層級問題（分層破裂、設計系統不嚴格、不是好的 CSS 學習路徑、HTML 對 cascade 說謊）——後者不是「用熟就好」，是設計上的取捨。
- 文中那段「
<p class="text-red-500 text-green-500">是紅色」的 demo，是少數能把「utility-first 跟 cascade 的根本衝突」講清楚的人話解釋，遠比純論述有效。 - 文章的時機剛好搭上 2026 年初 Tailwind Labs 裁員 75%、Adam 自承營收掉 80% 的爆料——「AI 寫 Tailwind 不查文件」這件事，反向證明了這套 class 系統高度可預測、可自動化，但也意味開發者不再覺得需要「學」它。
對台灣前端社群來說，這篇文章的價值在於：很多團隊是 2022–2024 跟著 React 生態一起把 Tailwind 引入的，現在是重新評估成本的好時機——不是「要砍掉」，而是「先想清楚你買的是哪一段」。
📊 數據解讀 / 質疑
1. 採用率 vs 抱怨率同時飆高
- npm 週下載量：Tailwind CSS 2026 年 1 月突破 3,000 萬次/週（technologychecker.io 整理），是 Bootstrap 的 5 倍；pkgpulse 顯示 v4.3.2 達 1.18 億次/週（含所有版本與鏡像）。
- State of CSS 2025：Tailwind 滿意度 81%，是所有 CSS 框架最高；開發者採用率 37–51%（依調查口徑）。
- 同期 Hacker News 上「Moving away from Tailwind」「Why Tailwind Isn’t for Me」「Tailwind marketing and misinformation engine」三篇批評文合計破千讚。
採用率跟抱怨率都飆高，代表生態正進入「主流化後必然反彈」階段——這不是 Tailwind 變差，是使用者基數變大後，踩到設計缺陷的人也變多。
2. 「採用率」不等於「設計 token 統一」
作者質疑的核心數字是：即使整個專案都用 Tailwind，設計系統一致性仍取決於紀律。w-[347px] 跟 text-[#1a2b3c] 仍可隨意寫。實務上 State of CSS 2025 顯示 35% 的 Tailwind 使用者承認「arbitrary values 用太多」。這數字不在 Tailwind 的行銷素材裡，但它是 utility-first 框架的結構性限制。
3. AI 對營收的衝擊反證了「class 是給人讀的」這個假設
Adam Wathan 2026 年 1 月 GitHub 公開信：營收掉 80%、裁 75% 員工，主因是 Cursor / Copilot / ChatGPT 直接產 Tailwind class、不需要查文件。這代表 class 系統對 LLM 而言極易生成——但對人類閱讀仍是負擔（作者主張）。當 AI 是主要寫手，Tailwind 的「可預測 utility」變成 AI 友善資產；當人類是主要讀者與維護者，class soup 就是技術債。
4. v4.0 引擎重寫的諷刺
Tailwind v4 的賣點是 CSS-first 設定、native cascade layer、@property、container queries——全部是原生 CSS 早有的東西。Tailwind 蓋在原生 CSS 之上，而作者的主張正是：如果平台已經提供這些，那 Tailwind 還剩多少必要？這個反問是文章最尖銳的一刀。
後續發展與不同觀點
Adam Wathan 截至發稿未對這篇文章正式回應。HN 留言區主流的兩種反駁：
- 「如果你還在寫 server-rendered 模板，沒用 component 框架——那當然不需要 Tailwind」：挺 Tailwind 派認為作者的場景已經過時，現代 React/Vue/Svelte 專案裡 HTML 跟樣式本來就 co-locate，沒差。
- 「沒有 Tailwind 的設計系統你還是得自己寫 token、寫 utility、寫 file structure——只是換個地方維護」：認為 utility-first 不是問題根源，沒有任何系統能取代人的設計紀律。
Andros 自己在文末的回答也很溫和：他說 Tailwind 不是壞工具，是有代價的工具，而那個代價在 2026 年開始跟現代原生 CSS 競爭。最終沒有 universal winner，只有 context。
給 Siami 讀者的行動建議
- 小團隊 + 沒 designer + React 元件為主：Tailwind v4 仍合理，省下的設計協調時間大於 class soup 成本。
- 大團隊 + 多人協作 + 多品牌：考慮 CSS Modules + design token（CSS variables），把一致性的責任放在 linting 與 PR review，不是 framework。
- 剛學前端：先寫 3 個月原生 CSS（含 cascade layer、@property、container queries、color-mix），再決定要不要用 Tailwind。
- 已在用 Tailwind 的專案：不用恐慌地砍掉。檢查
.vue/.tsx裡的 class 平均長度——如果超過 12 個 class 一行，那已經是技術債訊號。
Tailwind 的真問題從來不是「它能不能用」，而是「你為了它的便利，付出了多少未來的維護利息」。
資料來源
- Andros Fenollosa 原文：Why I don’t recommend Tailwind CSS
- Tailwind Labs 官方：Tailwind CSS v4.0 發表公告
- Tailwind Labs 官方 YouTube 教學頻道：Tailwind CSS v4 Full Course 2026
- Hacker News 討論串：Why I don’t recommend Tailwind CSS（8 月 2 日）
- 引用統計：State of CSS 2025、pkgpulse tailwindcss 統計、technologychecker.io 採用率報告
網友熱門留言 (5)