Hello，大家好，我是 Sunday。

說起 Tailwindcss 很多同學應該是熟悉的，它被稱之為是一個 原子級 css 框架，在之前我錄制的 Vue3 中前臺解決方案 這個課程中，就是使用的這個 css 框架。

圖片

不過，很多學生在使用這個框架的時候，產生了兩種截然不同的情緒：

• 第一種：Tailwind 用起來真爽，再也不用為 想類名 發愁了
• 第二種：這是個什么“狗屎”東西，一坨類名寫在一起，這將來能維護？幾天之后誰能看得懂啥是啥？

這兩種截然不同的情緒其實就反映出了 目前開發者對 tailwindcss 的看法。

那么為什么會出現這兩種截然不同的體驗，tailwindcss 到底值得用嗎？

想要搞明白這些，那么首先，我們需要先知道 為什么會出現 tailwindcss，也就是 tailwindcss 解決了什么問題？

tailwindcss 解決了什么問題？

Tailwind 是 2017 年發布的，最初發布的目的就是為了解決 CSS 維護困難的問題，這些問題大致包含三部分：

1. css 取名困難：這是一直非常核心的痛點。因為 css 多數情況下是基于 class 進行構建的。那么就會導致我們需要設置大量的 class 名。這就導致 “取名困難癥” 的出現。當初甚至還出現了 css類名大全 這種網站或庫。
2. 頻繁的切換視圖：傳統的 css 構建 html 和 css 是 分開的。這就需要開發者不斷地來回切換對應的視圖。
3. 靈活性不足：在大型項目中，我們經常會發現自己在不同的組件中重復定義相似的樣式。這就可能導致樣式沖突或需要頻繁重構。同時由于傳統 CSS 類常常過于籠統，不能很好地應對不同的設計需求。開發者需要創建大量的自定義類來覆蓋原有樣式。

因此 Tailwind 提供了這三種問題的對應解決方式：

1. 細粒度控制：Tailwind 提供了數百個預定義的、可組合的工具類（utility classes），可以直接在 HTML 中使用。不需要再讓你想類名了。
2. 提高開發效率：通過使用工具類，開發者可以在 HTML 中直接定義樣式，減少了在不同文件之間切換的時間，從而加快了開發速度。
3. 避免樣式沖突：由于 Tailwind 提供的類都是原子化的，避免了傳統 CSS 中樣式污染和命名沖突的問題。同時還提供了 可定制 的能力，我們可以通過配置文件來定制顏色、字體、間距等，以符合項目的設計需求。

tailwindcss 帶來了什么新問題？

看上面的描述好像是很棒的。但是 tailwindcss 也帶來了很多新的問題，這些新的問題就是很多同學 “討厭” 它的原因：

1. HTML 混亂和可讀性降低

這個具體體現在兩個方面：

• 類名堆疊：由于 Tailwind 的設計理念是直接在 HTML 中使用大量的工具類（utility classes），這可能會導致 HTML 變得“雜亂無章”，特別是在復雜的組件中，類名的堆疊可能非常龐大，影響代碼的可讀性。

圖片

• 難以理解的代碼：對于沒有使用過 Tailwind 的開發者來說，看到一堆無意義的類名（如 p-4, mt-2, text-blue-500）可能難以快速理解代碼的意圖和布局。

2. 樣式復用并不簡單

• 學習復雜度：對于剛接觸 Tailwind 的同學來說，大量的類名記憶是非常消耗心力的。想要理解如何有效地配置 Tailwind 學習曲線并不低。
• 復用并不簡單：雖然 Tailwind 提供了很多的工具類，但是在多人合作的團隊中，我們可能依然需要在多個地方重復相同的類名。特別是一些初創團隊，使用 Tailwind 可能導致相似的樣式在不同地方多次定義，增加了維護成本。

3. 生產環境的文件體積

• 生成的 CSS 文件較大：默認情況下，Tailwind 生成的 CSS 文件包含大量的工具類，這可能導致生成的文件體積較大，尤其是在沒有使用 tree-shaking 等技術來去除未使用的樣式時。這會影響頁面加載速度和性能。
• 依賴構建工具：為了優化 Tailwind 的輸出，通常需要依賴構建工具（如 PostCSS 或 PurgeCSS）來移除未使用的樣式，這增加了項目的構建復雜性。

如何看待 tailwindcss？

那么根據以上內容，其實我們也可以發現 Tailwind 并不適合所有人使用。

因此，也就出現了 擁抱 Tailwind 和 逃離 Tailwind，回歸 scss 的兩種截然不同，但又同時存在的 亂象。

在前端這個領域，這種亂象并不是僅存在于 Tailwind 這一個框架，而是存在于我們日常開發的方方面面。大家應該也經常有看到 兩種不同框架的開發者在網絡中互相 “攻伐” 的情況。

但是，如果讓我去說，我覺得：這都是 毫無意義 的！

技術本身在于 輔助業務，創造價值。

在這個過程中，業務是核心，價值是結果，技術是輔助核心完成結果的過程

大家想一想，如果我們 不去討論核心的業務，不去追溯最終的結果，而只是在過程中來回糾結，是不是就顯得有些舍本逐末了。

所以說：使用什么框架并不重要，感覺這個“工具”順手就繼續使用，不順手就把它“丟掉”。