🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付

這週我需要為一個按鈕加入一個簡單的懸停效果。沒什麼特別的,就是滑鼠懸停時改變背景顏色。

我盯著螢幕看了30秒,手指懸在鍵盤上方,卻怎麼也想不起來該怎麼寫。

並非因為我CSS技術不好。我從2017年就開始做網站了。我懂CSS。或者說,我曾經懂。

我怎麼也想不出這文法。我腦中立刻浮現hover:bg-blue-600這個樣式。那是 Tailwind 的風格,不是 CSS。

我突然意識到,我已經大概兩年沒寫過真正的 CSS 了。現在所有東西都用 Tailwind 了。類、工具類,沒有樣式表。

而且我不是唯一這麼想的人。 Tailwind 每週在 NPM 上的下載量超過 2000 萬次,比 Bootstrap 的 490 萬次還要多。這個框架無所不在,你最喜歡的網站和程式碼代理程式都在使用它。

但這裡有一個沒人問的問題:如果我們都忘記了 CSS 的實際運作原理,會發生什麼事?

一場誰也沒想到的收購

五年前,Tailwind 還是一些人嘗試使用的略顯怪異的實用工具優先框架。大多數開發者看到的程式碼都是這樣的:

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Click me
</button>

他說:“這太噁心了。這只是多了幾個步驟的內聯樣式而已。”

他們的說法並非完全錯誤。

但後來發生了一些事。開發者們開始使用它。然後他們就停不下來了。最後他們甚至忘了不用它該怎麼開發。

資料說明了一切。根據CSS現況調查,Tailwind的留存率高達70%以上。這意味著四分之三的開發者在試用後會繼續使用它。

相比之下,Bootstrap 的使用率約為 45%。而純 CSS 的使用率……嗯,人們不會「保留」CSS,因為它不是可選項,而是基礎。

但現在這成了一種選擇。而開發者們正在選擇 Tailwind。

為什麼每個人都在使用它(包括我)

我不會坐在這裡假裝 Tailwind 不好。我一直在用它。每個專案都用。現在我的肌肉記憶是 Tailwind 類,而不是 CSS 屬性。

它獲勝的原因如下:

速度

你無需在 HTML 和 CSS 文件之間切換。所有內容都在那裡。看到一個 div,設定它的樣式,然後繼續。無需在文件之間跳轉。無需命名類別名稱。無需擔心.button-primary是否已在其他地方定義。

一致性

你的間距保持一致,是因為你使用了預先定義的間距工具。 p p-4始終是相同的內邊距。 gap gap-8始終是相同的間距。不再需要憑感覺設定margin: 23px了。

不為事物命名

CSS 類別命名是程式設計中最難的問題之一。而使用 Tailwind,你無需命名任何內容。類別名稱本身就能描述其作用。例如flex items-center justify-between就直接說明了它的功能。

就是好用

你無需費力去糾結樣式特異性。你無需除錯樣式為何無法生效。你無需擔心某個類別是否在某處被覆蓋。 Tailwind 類別就是這麼好用。

它功能強大。這就是開發者喜歡它的原因。這也是我喜歡它的原因。

無人談及的問題

但有一件事一直困擾著我,我覺得你也應該感到困擾。

我們正在抽象化基礎知識

CSS其實並不難。 Flexbox、Grid、定位,這些都是Web平台的核心特性,它們不會被淘汰。但我們正在培養的整個開發者卻對這些特性一無所知。

我存取過一些初級開發人員,他們能準確地告訴我 Tailwind 類別中的justify-content: space-between作用,但卻寫不出實際的 CSS 屬性。

他們知道flex items-center ,但不知道align-items: center

他們知道w-64 ,但不知道width: 16rem ,也不知道為什麼會有 rem 這個單位。

這令人擔憂。

捆綁包大小謊言

Tailwind 自詡為能夠產生體積小巧的 CSS 檔案包。 “大多數專案最終交付的 CSS 檔案都不到 10kb!”

沒錯,你的CSS檔案很小。

但是你的 HTML 程式碼非常龐大。每個元素都有 5 到 15 個類別。你的 HTML 檔案比使用語意化 CSS 的檔案大 2 到 3 倍。

沒錯,HTML壓縮效果很好。但它仍然需要解析。瀏覽器仍然需要處理所有這些類別。

我統計了一下我們一個專案的資料。使用 Tailwind 後,CSS 檔案從 45kb 降到了 8kb,很棒!但 HTML 檔案卻從 120kb 增加到了 340kb,淨增加 183kb。

這一點在市場宣傳中並沒有提到。

你被鎖定了

想從 Tailwind 切換到其他框架?祝你好運。你的整個程式碼庫都是 Tailwind 類別。每個元件,每個頁面,到處都是成千上萬的實用類別。

從 Tailwind 遷移就像從 jQuery 遷移一樣。雖然可行,但過程極其痛苦,以至於大多數人乾脆放棄。

你學的不是 CSS,而是 Tailwind。如果 Tailwind 消失了或不再流行,那你該怎麼辦?

可讀性問題

請看以下來自生產環境應用的真實程式碼:

<div class="flex flex-col sm:flex-row items-start sm:items-center justify-between p-4 sm:p-6 bg-white dark:bg-gray-800 rounded-lg shadow-md hover:shadow-lg transition-shadow duration-200 border border-gray-200 dark:border-gray-700 space-y-4 sm:space-y-0 sm:space-x-4">

一個div元素裡居然有19個類別。你能一眼看出它們的作用嗎?不能。你得仔細琢磨每個類別的功能。

使用語意化 CSS:

<div class="card">

在你的 CSS 中:

.card {
  /* All the styles */
}

哪個比較易讀?哪個比較容易讓程式碼庫新手理解?

如果順風消失了會發生什麼事?

這件事讓我夜不能寐。不是因為我覺得 Tailwind 明天就會消失。它不會消失。它現在規模太大了。

但框架來來去去。還記得Bootstrap曾經稱霸網路嗎?還記得jQuery幾乎無所不在嗎?還記得Flash是製作互動式內容的唯一方法嗎?

所有這些看起來都是永久性的,但實際上沒有一個是永久性的。

Tailwind 由 Tailwind Labs 支援。它是一家公司。公司可能會被收購、倒閉、轉型,或只是因為某個框架不再獲利。

那麼,數百萬個 Tailwind 專案將會發生什麼變化呢?

你可能會說「它是開源的,社群會維護它。」沒錯。但是,你上一次看到一個流行的框架在失去核心團隊後還能保持發展勢頭是什麼時候?

看看 Ember,看看 Backbone,看看 Angular.js(不是 Angular,是 Angular.js)。它們在技術上仍在維護,但實際上都已經停止開發了。

我並不是預測 Tailwind 會消亡,我只是說它有可能消亡。如果它真的消亡了,那麼整個開發者產業就將面臨無法再寫 CSS 的局面。

真正的爭議(沒人願意說出口的)

接下來這個辛辣的觀點可能會激怒一些人:

Tailwind 就像永遠不會拆掉的輔助輪。

這是有意為之。

學騎腳踏車的時候,要先用輔助輪。最終,你會把輔助輪拆掉,然後真正騎車。

使用 Tailwind 時,一開始會用到一些實用類別。然後……你會一直用這些實用類別。永遠用不完。你永遠也擺脫不了這些輔助工具,永遠寫不出真正的 CSS。

這個框架並沒有鼓勵你學習底層平台,而是鼓勵你學習更多關於 Tailwind 的知識。

想做一些自訂設定?那就擴展你的 Tailwind 配置(我對新版本不太了解,別噴我,哈哈)。需要新的顏色?把它加到你的 Tailwind 主題。需要新的間距值?把它加到你的 Tailwind 間距縮放裡。

一切都在引導你更深入地使用 Tailwind,而不是更深入地使用 CSS。

這的確是高明的商業策略。用戶鎖定固然重要,但對網路平台而言並非好事。

CSS發展迅速。容器查詢、 has()選擇器、子網格、層疊圖層,所有這些強大的功能都正在瀏覽器中應用。

但是有多少 Tailwind 開發人員了解它們?又有多少人在使用它們?

Tailwind 透過一些實用工具支援其中一些功能。但你學習的是這些實用工具,而不是具體的功能。如果 Tailwind 目前還不支援某些功能,你可能永遠都不會用到它。

我正在採取的措施(以及你也應該採取的措施)

我仍然每天都在使用Tailwind。我不是來勸你停止使用它的。

但我正在做出一些改變:

每周有一天,沒有 Tailwind

星期五是我的「純CSS日」。如果我在做專案,我會寫真正的CSS程式碼,不用任何工具類,只寫普通的樣式表。

一開始確實很痛苦,但它能讓我保持CSS技能的熟練度。說實話,有時候還挺讓人耳目一新的。

首先教授初級CSS課程

當我指導初級開發人員時,我們不會從 Tailwind 開始,而是從 CSS 開始。 Flexbox、Grid、定位,這些都是基礎。

只有當他們能夠用純 CSS 建立佈局之後,我們才會引入 Tailwind。這樣他們才能理解他們所抽象的概念。

認真閱讀 CSS 規範

我訂閱了 CSS 的更新,閱讀了新功能介紹,並在專案中進行了嘗試。因為 CSS 仍在不斷發展,我不想讓 Tailwind 成為我了解 CSS 的唯一方法。

為複雜元件編寫語義化 CSS

對於真正複雜的元件,我會編寫真正的 CSS 程式碼。自訂屬性、計算、複雜的選擇器等等,這些都是工具類別難以實現甚至無法實現的。

這讓我無論身處哪個世界都能感到自在。

令人不安的真相

目前CSS的發展處境很尷尬。

該平台比以往任何時候都更加強大。容器查詢帶來了革命性的改變。級聯層解決了查詢優先級問題。嵌套功能終於實現了原生支援。

但如今真正編寫 CSS 的開發者比以往任何時候都少。

Tailwind 正在取得勝利。資料證明了這一點。用戶採納率證明了這一點。社區也證明了這一點。

也許這樣也挺好。也許抽象就是一種進步。我們抽象掉了彙編語言。我們抽象掉了C語言。我們抽象掉了jQuery的跨瀏覽器相容性問題。

或許將 CSS 抽象化是下一步合乎邏輯的做法。

但我始終無法擺脫這種感覺:我們正在失去一些重要的東西——理解和操控網路底層架構的能力。

當每個人都知道 Tailwind 而沒有人知道 CSS 時,誰來維護 Web 平台?

誰參與制定 CSS 規範?誰提交瀏覽器 bug?誰推動 CSS 發展?

如果答案是“沒有人,因為我們都在使用 Tailwind”,那就成問題了。

CSS 的未來究竟在哪裡?

當我們還在編寫flex items-center justify-between時,CSS 本身正在發展成為更強大的工具。

原生嵌套功能現已推出。現在您可以使用純 CSS 編寫 Sass 風格的巢狀選擇器。

容器查詢允許元件根據其容器大小而非視口大小進行響應式設計。這非常重要,Tailwind 也勉強支持它,但大多數開發者並不使用它。

has()選擇器是一個父級選擇器。你可以根據子級元素來設定父級元素的樣式。這在過去幾十年是不可能的,現在終於實現了。

視圖過渡 API 可實現流暢自然的頁面過渡效果,無需 JavaScript 框架。

層疊結構讓你可以對樣式優先權進行精細控制。你終於可以擺脫樣式優先權衝突的困擾,輕鬆組織你的 CSS 程式碼了。

所有這些都是原生 CSS 功能,瀏覽器層級的特性,無需建立步驟,無需框架,開箱即用。

但是有多少開發者在使用這些工具呢?又有多少開發者知道這些工具的存在?

Tailwind 為其中一些功能加入了實用工具,但速度很慢,而且只有在符合他們以實用工具為先的商業模式時才會這樣做。

同時,原生 CSS 的發展速度遠遠超過任何框架所能跟上的速度。

我們應該問的問題

不再是「我該不該用Tailwind?」這個問題了。這個問題已經過時了。我們大多數人都在用或將來都會用。

問題是:“如何在不忘記平台的情況下使用 Tailwind?”

因為真正的風險就在於此。並非說 Tailwind 不好,而是它太好了,以至於我們不再去了解它背後的原理。

當下一個重大事件發生時(它一定會發生),我們將毫無準備。

我們將成為 Tailwind 開發人員,而不是 Web 開發人員。

而這種差異至關重要。

我的真實感受(使用 Tailwind 三年後)

我並不討厭 Tailwind。我每天都用它。它讓我的工作效率更高。我的團隊也因此提高了工作效率。

但我擔心這個行業。擔心那些認為 CSS 只是 Tailwind 類別的初級開發人員。擔心那些對單一框架依賴性過強,以至於無法遷移的程式碼庫。

展望未來,“前端開發人員”意味著“了解 Tailwind”,而不是“了解 Web 平台”。

也許我錯了。也許這只是進步,而我只是像個老頭子對著雲朵咆哮一樣,懷念起寫 CSS 檔案的日子。

但我並不這麼認為。

我認為我們是在用短期生產力換取長期知識。而這種權衡只有在 Tailwind 永遠佔據主導地位的情況下才有意義。

這是一個很大的假設。

你可以做什麼

如果你正在使用 Tailwind(你很可能正在使用),以下是我的建議:

不要停止學習 CSS。花時間研究實際屬性。理解你所抽象的概念。閱讀 CSS 規範。嘗試新功能。

在教授 Tailwind 之前,先教初級程式設計師 CSS。確保他們在學習抽象層之前理解 CSS 的基礎知識。

偶爾寫點原生 CSS 程式碼,保持技能熟練,說不定哪天就用上了。

密切關注原生 CSS 的發展。這個平台變化很快,不要只依賴 Tailwind 來了解它。

預留一些遷移空間。不要讓整個程式庫 100% 都使用 Tailwind CSS。保留一些自訂 CSS。即使遷移的可能性不大,也要確保遷移的可行性。

質疑框架。 Tailwind聲稱某些做法是“最佳實踐”,並不意味著它是最佳實踐。對你正在建構的東西進行批判性思考。

底線

Tailwind 贏了。資料證明了這一點。採用率也證明了這一點。如果你在 2025 年還反對 Tailwind,那你已經輸了。

但勝利並不意味著完美,受歡迎也不意味著這就是最終答案。

CSS是平台,Tailwind是工具,不要混淆兩者。

使用工具,但要尊重平台,學習平台,並為平台做出貢獻。

因為當下一個框架出現時(它一定會出現),這個平台依然會存在。

你需要知道這一點。


你的看法呢?你是不是也忘了CSS?還是我想太多了?

留下你的想法。讓我們像開發者一樣在評論區討論。

艾維斯·索特

請在x 上關注我 @elvisautet

資深全端開發工程師 | 偶爾還會寫 CSS

如果你覺得不舒服,那就對了。但還是要說出來。我們需要這樣的對話。


原文出處:https://dev.to/elvissautet/tailwind-css-won-the-war-but-were-the-losers-4877


精選技術文章翻譯,幫助開發者持續吸收新知。

共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
🏆 本月排行榜
🥇
站長阿川
📝14   💬4   ❤️5
467
🥈
我愛JS
📝1   💬4   ❤️2
49
🥉
酷豪
1
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次
🔧 阿川の電商水電行
Shopify 顧問、維護與客製化
💡
小任務 / 單次支援方案
單次處理 Shopify 修正/微調
⭐️
維護方案
每月 Shopify 技術支援 + 小修改 + 諮詢
🚀
專案建置
Shopify 功能導入、培訓 + 分階段交付