前端社群常見的宗教戰(zhàn)爭(zhēng)文：TailwindCSS根本邪魔歪道， Class根本不是這樣用的， 看了真他媽一肚子火 —— 硬派本格 CSS/SCSS支持者。

會(huì)有這樣的言論，也許是你日常的工作流程中，不適合用這樣的框架，又或許是你沒有客觀的理解過 TailwindCSS 的優(yōu)點(diǎn)所以體會(huì)不到它的魅力。

先說結(jié)論：如果你是一個(gè)團(tuán)隊(duì)做 SAAS 產(chǎn)品，需要在統(tǒng)一的產(chǎn)品風(fēng)格主題上面展開，并且使用 React 之類可以模塊化x組件的前端框架，那麼 TailwindCSS 會(huì)是很值得導(dǎo)入的樣式解決方案。

命名

我發(fā)現(xiàn)對(duì)我來說，打斷心流狀態(tài)的往往是幫組件取名這件事，在傳統(tǒng)使用 CSS/SCSS 上，我需要停下來花時(shí)間想一組組件還有其子組件的 class name 命名，檢查會(huì)不會(huì)跟已存在的元件衝突，多這一個(gè)步驟其實(shí)對(duì)開發(fā)效率上來講是拖累的。

誠然，你可以透過 Nested classes / BEM 之類的一些命名策略來讓這樣的步驟有一致性并減少命名碰撞，但在寫 JS 部分的組件時(shí)候已經(jīng)要命名組件/命名變量，命名東命名西了，很多時(shí)候你 CSS 也只是把 JS 定義的名字改改文字格式複制貼上。

例如這邊有個(gè)組件 AwesomeCard。

AwesomeCard -> .awesomecard
AwesomeCardIcon -> .awesomecard__icon
AwesomeCardBody -> .awesomecard__body
AwesomeCardButton -> .awesomecard__button

說穿了其實(shí)是浪費(fèi)生命的重複動(dòng)作。

下面還有一種情境的命名我也常常“頓爹”打斷我思路。

<div class="flex items-center justify-between px-3">
  <div class="flex items-center">
    <Icon/>
    <span class="ml-1">Label</span>
  </div>
  <Caret />
</div>

有時(shí)候你會(huì)需要一些額外的 div 搭配 flex 來做佈局，例如上面的代碼中，我想要 Icon 跟 Label 兩者垂直置中，這一組組件要跟 Caret 垂直置中并分別對(duì)齊左右邊界，轉(zhuǎn)成 CSS 你可能就需要用上好幾個(gè) classes。

<div class="btn__container">
  <div class="btn__leftgroup">
    <div class="btn__icon" />
    <span class="btn__label">Label</span>
  </div>
  <div class="btn__caret"/>
</div>

要額外命名 btn__container btn__leftgroup 會(huì)讓我很煩躁，這些步驟如果能省起來個(gè)人是覺得能大幅提升開發(fā)效率。

文件之間的切換

另外一個(gè)影響工作心流的是分開的 HTML/JS/CSS 文件 ，雖然說 separation of concern 是軟件工作中很重要的一個(gè)概念，但前端實(shí)務(wù)上，三種文件的耦合度極高，通常改一者就必須改另外兩者，頻繁的切換文件其實(shí)很沒有效率。

以 React 框架來說，已經(jīng)讓 Html 整合到 JSX 當(dāng)中，當(dāng)你習(xí)慣了這樣的工作模式，你會(huì)想更進(jìn)一步的把樣式定義也納進(jìn)來，這也是為什麼會(huì)有各種 css-in-js 的解決方案，TailwindCSS 在某種程度上也算是 css-in-js 的一種，各種組件狀態(tài)邏輯，例如說點(diǎn)選之后改變文字/背景顏色，可以透過 JSX 直接切換 className 來實(shí)現(xiàn) (搭配 classnames 這樣的 npm module 更是如虎添翼)。

統(tǒng)一的風(fēng)格樣式

如果是 SAAS 產(chǎn)品，你會(huì)希望整個(gè)團(tuán)隊(duì)有一致的調(diào)色盤， 而字體大小，間隔，常用寬高等維持有限度的選擇，讓你在組件佈局上能更好的對(duì)齊，TailwindCSS 這點(diǎn)已經(jīng)幫你把最常見的 text/bg color、font-size、spacing 都提取出來，框架初始自帶的設(shè)定已經(jīng)十分夠用，通常只需針對(duì)產(chǎn)品品牌色定義色盤，其他參數(shù)要客制修改擴(kuò)充透過設(shè)定檔也十分方便。

你可能會(huì)說，SCSS裡面我也可以定義各種變量啊，的確，但變成你要自己設(shè)立一套參數(shù)規(guī)則或是參考某個(gè)框架范本 (MUI/AntD/Bootstrap) 來實(shí)作。

然后又回到一個(gè)懶人想省打字的問題上了，究竟是：

<div class="bg-gray-100">...</div>

還是：

<div class="card"></div>
.card {
  background-color: $gray100
}

對(duì)我來說，差別其實(shí)蠻明顯的。

冗長的 class name

<div class="w-96 bg-white shadow rounded flex items-center">...</div>

通常反對(duì) TailwindCSS 的正統(tǒng)硬派 CSS 使用者，最常攻擊的就是 Atomic utility classes 冗長的 class name，但這個(gè)透過 React 的組件封裝，其實(shí)根本不會(huì)是問題，通常你會(huì)把這些複雜度藏在可重複使用的組件中，實(shí)際上在開發(fā)的時(shí)候，代碼往往是很清爽好讀的。

例如底下一個(gè) navigation 的組件，在 DOM tree 裡面長這樣。

<ul class="flex">
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
  <li class="mr-6"><a class="text-blue-500 hover:text-blue-800" href="#">Link</a></li>
</ul>

可以把 li 給抽出來寫成獨(dú)立的組件。

const NavItem = ({ href, children }) => <li class="mr-6"><a className="text-blue-500 hover:text-blue-800" href={href}>{children}</a></li>

如此一來，你的JSX源碼就能整理成以下比較好讀的格式。

<ul className="flex">
  <NavItem href="#">Link</NavItem>
  <NavItem href="#">Link</NavItem>
  <NavItem href="#">Link</NavItem>
</ul>

當(dāng)然，前提是搭配 React 這樣可以輕易封裝組合組件的框架才能發(fā)揮最大功效，如果沒有用上類似框架，我也不能否認(rèn) atomic css 的 class 是真的很冗長難讀。

文件更小的 Stylesheet

這點(diǎn)其實(shí)毋庸置疑，因?yàn)橛泻艽蟛糠值?Utility class 都是共用，沒有多馀命名，TailwindCSS 又自帶 Tree Shaking，不會(huì)產(chǎn)生沒用到的 class，整體的 CSS stylesheet 文件可以壓到很小，瀏覽器載入超快速。

總結(jié)

老話一句，工具沒有好壞，只有適不適合，就我個(gè)人開發(fā)經(jīng)驗(yàn)，導(dǎo)入 TailwindCSS 在 Developer Experience 上是頗受團(tuán)隊(duì)好評(píng)的，近年 TailwindCSS 的竄起，如果它沒有解決一些痛點(diǎn)，又何來這麼多人吹捧？

如果只是心理過不去，還抱持著寫傳統(tǒng) CSS 方法的驕傲與矜持，沒有客觀的去理解新工具以及其適用的場(chǎng)景，我是覺得蠻可惜的，畢竟用得好的話，它真的能為你帶來更好的生產(chǎn)力以及效率，團(tuán)隊(duì)協(xié)作上面也因?yàn)橛泄餐臉?biāo)準(zhǔn)而能夠和諧的運(yùn)作，何樂而不為？