在尚未前端開發這個概念的時代，CSS 其實做爲一個比較簡單的 DSL 還相對湊合夠用，但隨着前端項目愈來愈複雜，前端各類開發模式都在隨着項目規模擴大的需求而不斷進化，好比前端服務上咱們由服務端直出變爲簡單的先後端分離再慢慢的升級成先後端融合的 serverless，再好比 JS 的寫法上咱們從開始最原始的單文件腳本慢慢引入了各類模塊化的方案再到今天組件化全面開花。一樣的進化固然也會發生在 CSS 的開發上。javascript
CSS 做爲一個（曾經）只有全局做用域的 DSL 其實歷來都不適合大型工程，畢竟 HTML 被髮明時只是用來寫文檔，CSS 也只是爲了加些簡單的樣式而不是設計用於富應用的。但隨着前端項目規模的擴大， CSS 也不得不適應這一歷史進程。在 node 剛剛被髮明先後那段時間前端工程化還不是很成熟的階段，工程師們想了各類辦法來儘可能緩和這一矛盾，好比 BEM、OOCSS、SMACSS 等命名方案來分離關注點，又好比 less、Sass 等工具豐富一下 CSS 的語法而且能夠有一個 build 的過程使 CSS 有了初級的模塊化能力。但 CSS 不適用於大型工程的問題依然嚴重，Facebook 的開發經理（也是 prettier 的做者之一）vjeux 在 2014 年的一次演講[1]中總結了 CSS 不適用於大型項目的幾個痛點。css
Why CSS modules
CSS modules 就是爲了解決上面那些痛點而被髮明的，具體的原理就是經過編譯生成全局惟一類名，從而徹底不用類名樣式擔憂衝突。它很好的解決了項目規模增大的問題，配合 less 或者 Sass 這種預處理器也能夠實現至關程度的工程化，對於大部分的場景他已經足夠使用。但 CSS modules 也有着他本身的缺點：html
-
若是你重度使用了 less 或者 Sass 這種預處理器，引入了各類變量、mixin、函數等等特性，會形成 JS 和 CSS 中工程化生態的割裂。 -
很差刪代碼：一來只要是 CSS 文件就讓人有 copy-paste 的慾望很容易形成代碼的冗餘，二來 CSS 文件裏的類無法和外面的 JS 代碼關聯起來，須要藉助額外的工具才能引入類型系統。雖然不必定會影響最終的代碼體積（ PurgeCSS [2]），但對於工程的可讀性和可維護性仍是有必定污染的。
我的還有很討厭 CSS modules 的一點就是一旦你用 CSS modules 你就必須得分兩個文件，對於可讀性的影響積累下來其實很是大，碰到一個稍微複雜一點的組件就得左右兩頭來回改。現代基於組件的 web 開發其實更適合把模板、邏輯、樣式都儘可能放在一塊兒，最好是放在一個文件[3]裏。前端
Why CSS in JS
其實相比於 CSS modules，CSS in JS 的方案被 vjeux 提出的時間要更早，固然最開始的 CSS in JS 基本上能夠理解爲單純的把行內樣式放到對象裏去，與目前流行的基於 Tagged Templates 的 CSS in JS 方案差異很是大。vue
得益於組件化理念深刻人心，開發者們再也不關心具體的 HTML 和 CSS，複用組件就是安裝引入 npm 包後直接使用。CSS in JS 的方案能夠很好的契合這一開發方式，開發者不須要引入 CSS，再也不需額外處理 CSS 的 bundle、prefix，全部都是 JS 也就再也不須要配置各類 CSS 預處理器，極大下降了開發成本。java
CSS in JS 實際上是個挺口水的話題，由於在開發理念、工程成本、開發場景適配等等方面都有不少能夠講的。鑑於本文主要是安利 tailwind 就不展開了。目前最流行的 CSS in JS 方案是 styled-components，另外其實還有我的認爲更強大的 emotion 也有很多用戶，都是好東西。node
Why Tailwind CSS
https://tailwindcss.com/react
Tailwind CSS 其實就是把在現代工程化框架裏把原子 CSS 作到極致的一個 CSS 框架。其實原子 CSS 很早就出現了，最經典的如 clearfix ，在不少早期的 web 項目裏都會有或多或少的原子 CSS。但早期的原子 CSS 並不被認爲是一種最佳實踐，或者說被認爲是一種不好的方案。那個時代提倡所謂的「關注點分離」，HTML 的 class 應該有本身的語義，不該該把樣式或者邏輯附在上面。不過隨着時代的發展，在組件化流行的今天咱們其實已經並不怎麼關心 HTML 的語義（甚至那都不是 HTML，叫 JSX），語義化的功能已經被組件所取代了。對於每個 div 標籤，咱們關心的其實只有他的樣式。在這種背景下原子 CSS 就顯得頗有用了。web
使用統一的「系統」變量能夠極大減少心智負擔。
若是我如今須要把這個按鈕的背景色變成「那個」藍色，你該怎麼寫？npm
在今天一個稍微嚴肅一點的前端項目，都會有一套所謂的「設計語言」（哪怕是直接套用現有的），他會規範頁面中各類元素的「Design Token」，好比藍色是那個藍，紅色是哪一個紅，圓角是多少間距是多少。如今好比說我須要把須要把這個按鈕的背景色變成藍色，你該怎麼寫？只是爲了完成需求那笨辦法有不少無庸贅述，但咱們其實應該把這個咱們所用的設計語言的「Design Token」在工程裏維護起來。tailwind 自然就支持這一點。
// BAD
.button {
background: #3370ff; // 不知道哪裏來的神祕字符串
}
// GOOD
.button {
@apply bg-blue-500; // blue-500 是咱們設計語言中規定的正藍色
}
再好比咱們的項目的 CSS 中常常會有各類神祕數字，好比 17px、27px、35px 這種，這種 magic number 積累多了之後其實對於心智負擔至關大，由於你並不知道該選擇哪一個數字合適只能看着調。使用 tailwind 規定了「Design Token」以後能夠很大程度緩解這一點。其實對於設計師來講，基於 4px 的設計方案也是一種好的選擇[4]。
// BAD
.sliceContainer {
padding: 24px 24px 13px; // why 13 ?
}
// GOOD
.sliceContainer {
@apply px-6 pt-6 pb-3;
}
使用原子類能夠大大減小須要起名的場景
命名能夠算是開發中最難的事情之一，尤爲是在組件化開發已經深刻人心的今天，你其實徹底不必給你的 div 起一個有意義的名字。使用這個組件的頁面並不會關心你組件的頂部叫 header，底部叫 footer（除非你是些基礎組件須要給外界複用），你只須要把樣式放上去就行了。
你起過多少 wrapper、container、content、box、section、fragment 這種沒意義的 className？
一樣一段代碼，不用起名字能夠少掉很多頭髮
也許有人會以爲大量的內聯樣式類很很差維護，不過就咱們實踐下來的幾個大型項目的經驗來講，相比 CSS modules ，行內樣式在可維護性上實際上是要更好一些的。
與組件內聯能夠更好的實現「高內聚低耦合」
全部使用 CSS（包括 CSS modules）的解決方案其實都有一個問題，就是很差刪代碼：你很難肯定這段樣式是否是真的沒用了，直到出線上事故爲止。使用 tailwind css 你可讓樣式到死都跟着組件走，組件刪了樣式也就去掉了，幾乎零成本的下降了冗餘代碼的可能性。
Utility-First, not Utility-Only
最後，使用 tailwind 不是一個必選項，他能夠很好的和其餘方案結合着使用，用它也幾乎不會帶來任何成本。在原子樣式或者說「Design Token」上有更爲激進需求的能夠考慮 chakra，幾乎就是 tailwind 的 react/vue 版。
參考閱讀
React: CSS in JS – NationJS[5]
CSS Modules Welcome to the Future[6]
CSS Utility Classes and Separation of Concerns[7]
Why Tailwind CSS[8]
參考資料
演講: https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html
[2]PurgeCSS: https://purgecss.com/
[3]放在一個文件: https://vuejs.org/v2/guide/single-file-components.html#What-About-Separation-of-Concerns
[4]好的選擇: https://www.uisdc.com/4px-design
[5]React: CSS in JS – NationJS: https://blog.vjeux.com/2014/javascript/react-css-in-js-nationjs.html
[6]CSS Modules Welcome to the Future: https://glenmaddern.com/articles/css-modules
[7]CSS Utility Classes and Separation of Concerns: https://adamwathan.me/css-utility-classes-and-separation-of-concerns
[8]Why Tailwind CSS: https://www.swyx.io/why-tailwind
END
「分享、點贊、在看」 支持一波
本文分享自微信公衆號 - 大前端技術沙龍（is_coder）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。