建站
咨詢
售后
建站咨詢
新聞中心
前端社群常見的宗教戰(zhàn)爭文：TailwindCSS根本邪魔歪道， Class根本不是這樣用的， 看了真他媽一肚子火 —— 硬派本格 CSS/SCSS支持者。
成都創(chuàng)新互聯(lián)是專業(yè)的城廂網(wǎng)站建設(shè)公司，城廂接單;提供成都網(wǎng)站制作、做網(wǎng)站,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行城廂網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!
會有這樣的言論，也許是你日常的工作流程中，不適合用這樣的框架，又或許是你沒有客觀的理解過 TailwindCSS 的優(yōu)點所以體會不到它的魅力。
先說結(jié)論：如果你是一個團隊做 SAAS 產(chǎn)品，需要在統(tǒng)一的產(chǎn)品風(fēng)格主題上面展開，并且使用 React 之類可以模塊化x組件的前端框架，那麼 TailwindCSS 會是很值得導(dǎo)入的樣式解決方案。
命名
我發(fā)現(xiàn)對我來說，打斷心流狀態(tài)的往往是幫組件取名這件事，在傳統(tǒng)使用 CSS/SCSS 上，我需要停下來花時間想一組組件還有其子組件的 class name 命名，檢查會不會跟已存在的元件衝突，多這一個步驟其實對開發(fā)效率上來講是拖累的。
誠然，你可以透過 Nested classes / BEM 之類的一些命名策略來讓這樣的步驟有一致性并減少命名碰撞，但在寫 JS 部分的組件時候已經(jīng)要命名組件/命名變量，命名東命名西了，很多時候你 CSS 也只是把 JS 定義的名字改改文字格式複制貼上。
例如這邊有個組件 AwesomeCard。
AwesomeCard -> .awesomecard
AwesomeCardIcon -> .awesomecard__icon
AwesomeCardBody -> .awesomecard__body
AwesomeCardButton -> .awesomecard__button
說穿了其實是浪費生命的重複動作。
下面還有一種情境的命名我也常?！邦D爹”打斷我思路。
Label
有時候你會需要一些額外的 div 搭配 flex 來做佈局，例如上面的代碼中，我想要 Icon 跟 Label 兩者垂直置中，這一組組件要跟 Caret 垂直置中并分別對齊左右邊界，轉(zhuǎn)成 CSS 你可能就需要用上好幾個 classes。
Label
要額外命名 btn__container btn__leftgroup 會讓我很煩躁，這些步驟如果能省起來個人是覺得能大幅提升開發(fā)效率。
文件之間的切換
另外一個影響工作心流的是分開的 HTML/JS/CSS 文件 ，雖然說 separation of concern 是軟件工作中很重要的一個概念，但前端實務(wù)上，三種文件的耦合度極高，通常改一者就必須改另外兩者，頻繁的切換文件其實很沒有效率。
以 React 框架來說，已經(jīng)讓 Html 整合到 JSX 當(dāng)中，當(dāng)你習(xí)慣了這樣的工作模式，你會想更進一步的把樣式定義也納進來，這也是為什麼會有各種 css-in-js 的解決方案，TailwindCSS 在某種程度上也算是 css-in-js 的一種，各種組件狀態(tài)邏輯，例如說點選之后改變文字/背景顏色，可以透過 JSX 直接切換 className 來實現(xiàn) (搭配 classnames 這樣的 npm module 更是如虎添翼)。
統(tǒng)一的風(fēng)格樣式
如果是 SAAS 產(chǎn)品，你會希望整個團隊有一致的調(diào)色盤， 而字體大小，間隔，常用寬高等維持有限度的選擇，讓你在組件佈局上能更好的對齊，TailwindCSS 這點已經(jīng)幫你把最常見的 text/bg color、font-size、spacing 都提取出來，框架初始自帶的設(shè)定已經(jīng)十分夠用，通常只需針對產(chǎn)品品牌色定義色盤，其他參數(shù)要客制修改擴充透過設(shè)定檔也十分方便。
你可能會說，SCSS裡面我也可以定義各種變量啊，的確，但變成你要自己設(shè)立一套參數(shù)規(guī)則或是參考某個框架范本 (MUI/AntD/Bootstrap) 來實作。
然后又回到一個懶人想省打字的問題上了，究竟是：
...
還是：
.card {
background-color: $gray100
}
對我來說，差別其實蠻明顯的。
冗長的 class name
...
通常反對 TailwindCSS 的正統(tǒng)硬派 CSS 使用者，最常攻擊的就是 Atomic utility classes 冗長的 class name，但這個透過 React 的組件封裝，其實根本不會是問題，通常你會把這些複雜度藏在可重複使用的組件中，實際上在開發(fā)的時候，代碼往往是很清爽好讀的。
例如底下一個 navigation 的組件，在 DOM tree 裡面長這樣。
可以把 li 給抽出來寫成獨立的組件。
const NavItem = ({ href, children }) => 如此一來，你的JSX源碼就能整理成以下比較好讀的格式。
當(dāng)然，前提是搭配 React 這樣可以輕易封裝組合組件的框架才能發(fā)揮最大功效，如果沒有用上類似框架，我也不能否認 atomic css 的 class 是真的很冗長難讀。
文件更小的 Stylesheet
這點其實毋庸置疑，因為有很大部分的 Utility class 都是共用，沒有多馀命名，TailwindCSS 又自帶 Tree Shaking，不會產(chǎn)生沒用到的 class，整體的 CSS stylesheet 文件可以壓到很小，瀏覽器載入超快速。
總結(jié)
老話一句，工具沒有好壞，只有適不適合，就我個人開發(fā)經(jīng)驗，導(dǎo)入 TailwindCSS 在 Developer Experience 上是頗受團隊好評的，近年 TailwindCSS 的竄起，如果它沒有解決一些痛點，又何來這麼多人吹捧？
如果只是心理過不去，還抱持著寫傳統(tǒng) CSS 方法的驕傲與矜持，沒有客觀的去理解新工具以及其適用的場景，我是覺得蠻可惜的，畢竟用得好的話，它真的能為你帶來更好的生產(chǎn)力以及效率，團隊協(xié)作上面也因為有共同的標(biāo)準(zhǔn)而能夠和諧的運作，何樂而不為？
文章題目：客觀評價增長趨勢比Vite還猛的TailwindCSS
瀏覽地址：http://fisionsoft.com.cn/article/dhoppec.html
