現在大部分搞前端的應該還是這樣寫 CSS 的： 

.mock { 
    margin: auto; 
    font-size: 16px; 
    // ... 
} 
<div class='mock'>mock</div> 

 以上代碼就是舉個例子，大部分情況應該都是寫一個類，然后整一堆樣式進去。

但是這種方式寫多了以后，你應該會感受到一些痛點，比如說：

• 取名困難，節點結構一多，取名真的是個難事。當然了，我們可以用一些規范或者選擇器的方式去規避一些取名問題。
• 需要用 JS 控制樣式的時候又得多寫一個類，尤其交互多的場景。
• 組件復用大家都懂，但是樣式復用少之又少，這樣就造成了冗余代碼變多。
• 全局污染，這個其實現在挺多工具都能幫我們自動解決了。
• 死代碼問題。JS 我們通過 tree shaking 的方式去除用不到的代碼減少文件體積，但是 CSS 該怎么去除?尤其當項目變大以后，無用 CSS 代碼總會出現。
• 樣式表的插入順序影響了 CSS 到底是如何生效的。
• 等等，不一一說明了。其實對于筆者而言，第一二塊在開發中是最難受的兩個點，尤其是剛寫前端，需要做活動 / 產品頁的時候。

當下，社區里有一些 CSS 方案，能夠解決以上一些痛點：

• Atom CSS
• CSS-in-JS
• 上述兩者的結合體

本文就來聊聊以上三種方案的優缺點以及各自方案的代表作。

Atom CSS

首先來聊聊啥叫做 Atom CSS：意思是一個類只干一件事，比如說： 

.m-8 { 
    margin: 8px; 
} 

想象一下你按照這樣的思想搞出一大堆類似的類名，就能整出一個踐行 Atom CSS 方案的三方庫了，tailwindcss 就是這個方案里的佼佼者。其實 Atom CSS 很多人應該早都用過了，柵格系統上就有它的身影，無非不清楚原來它就是 Atom CSS 罷了。

我們先來看看如果用 tailwindcss 的話，寫好樣式的 HTML 大概長啥樣：  

 

上圖是人家官網上的，在這之前還有一段挺炫的動畫。看起來好像挺方便的，寫上一堆類名就能出左邊好看的樣式了，省了很多寫樣式的時間，但是讀者們可以來想想這種方式它會有啥好處及弊端?

在說優缺點之前，我們先來聊聊 Atom CSS 的歷史。其實它并不是一個新興產物，這玩意你往前推個十年就能看到它的討論。正所謂天道好輪回，蒼天饒過誰。Atom CSS 以前火過，而且是被噴火的，沉寂了幾年之后這幾年又被拿出來說了。

接下來我們以 tailwindcss 為例來聊聊 Atom CSS 方案的優劣點。

優劣點

如果你想在團隊內部推廣這個產品，學習成本會是一個問題，畢竟需要大家都看得懂你這坨東西到底是啥意思，這算一個很明顯的缺陷。但是對于語法問題你還真的不用怎么擔心，tailwindcss 是有語法補全的工具鏈的，Webstorm 已經內置了，VSCode 需要大家自行裝個插件，所以噴寫 tailwindcss 語法麻煩的可以歇一歇。

樣式復用，就像寫組件一樣，這次我們是把樣式一個個抽離了出來，這樣帶來的一大好處是減少了 CSS 代碼文件體積。

原本傳統的寫法是定義一個類，然后寫上需要的樣式： 

.class1 { 
    font-size: 18px; 
    margin: 10px; 
} 
.class2 { 
    font-size: 16px; 
    color: red; 
    margin: 10px; 
} 

這種寫法是存在一部分樣式重復的，換成 Atom CSS 就能減少一部分代碼的冗余。

把 CSS 當成組件來寫。大家乍一看 tailwindcss 官網肯定會覺得我在 HTML 里寫個樣式要敲那么多類是有病吧? 

<figure class="md:flex bg-gray-100 rounded-xl p-8 md:p-0"> 
  <img class="w-32 h-32 md:w-48 md:h-auto md:rounded-none rounded-full mx-auto" src="/sarah-dayan.jpg" alt="" width="384" height="512"> 
  <div class="pt-6 md:p-8 text-center md:text-left space-y-4"> 
    <blockquote> 
      <p class="text-lg font-semibold"> 
        “Tailwind CSS is the only framework that I've seen scale 
        on large teams. It’s easy to customize, adapts to any design, 
        and the build size is tiny.” 
      </p> 
    </blockquote> 
    <figcaption class="font-medium"> 
      <div class="text-cyan-600"> 
        Sarah Dayan 
      </div> 
      <div class="text-gray-500"> 
        Staff Engineer, Algolia 
      </div> 
    </figcaption> 
  </div> 
</figure> 

其實我們是可以利用 Atom CSS 一次只干一件事的特性，將這些類隨意組裝成我們想要的類，這樣就可以提供出來一個更上層的通用樣式來復用。

比如說項目中的按鈕都是存在通用的圓角、內邊距、字體等，這樣我們就可以封裝出這樣一個類： 

.btn { 
    @apply p-8 rounded-xl font-semibold 
} 

效率工具。tailwindcss 用的好肯定是能提高寫布局的效率的，尤其對于需要做響應式的頁面而言。當然這東西其實也算是甲之蜜糖乙之砒霜，評價兩極分化很嚴重，有人認為提高了效率，也有人認為反而是增加了成本，或者說是脫褲子放屁。

提供了一整套規范化的設計模式，直接點說就是 tailwindcss 給你內置好一套優秀的設計主題了。但是這玩意對于規范的視覺團隊來說是個不小的福音，不規范的話就可能是火葬場了。下面我給大家舉個例子： 

// tailwind.config.js 
const colors = require('tailwindcss/colors') 
 
module.exports = { 
  theme: { 
    screens: { 
      sm: '480px', 
      md: '768px', 
      lg: '976px', 
      xl: '1440px', 
    }, 
    colors: { 
      gray: colors.coolGray, 
      blue: colors.lightBlue, 
      red: colors.rose, 
      pink: colors.fuchsia, 
    }, 
    fontFamily: { 
      sans: ['Graphik', 'sans-serif'], 
      serif: ['Merriweather', 'serif'], 
    }, 
    extend: { 
      spacing: { 
        '128': '32rem', 
        '144': '36rem', 
      }, 
      borderRadius: { 
        '4xl': '2rem', 
      } 
    } 
  } 
} 

以上是 tailwindcss 的主題配置文件，大家可以按照視覺的要求來做調整。比如說今天視覺覺得屏幕的 lg 尺寸應該是 976px，過段時間又覺得需要改成 1000px。對于開發者而言我們只需要修改一行代碼就能全局生效了，很舒服。

但是假如說視覺原本定義的邊距規則如下： 

// tailwind.config.js 
module.exports = { 
  theme: { 
    spacing: { 
      px: '1px', 
      0: '0', 
      0.5: '0.125rem', 
      1: '0.25rem', 
      1.5: '0.375rem', 
      2: '0.5rem', 
      2.5: '0.625rem', 
      3: '0.75rem', 
      3.5: '0.875rem', 
      4: '1rem', 
      5: '1.25rem', 
      6: '1.5rem', 
      7: '1.75rem', 
      8: '2rem', 
      // ... 
    }, 
  } 
} 

現在需要我們把 6 換成 1.6rem，但是這個規則只需要作用在某些組件上，此時我們需要如何修改樣式?新增一個 spacing 然后一個個去替換需要的地方么?

上述場景筆者認為還是不少見的，最起碼在我們公司內部是存在這樣的問題。已經定義了視覺規范并體現在內部的組件庫上，但是在業務中還是有不少視覺會去動組件的基本樣式，這里改個邊距，那里改個顏色等等。原本組件庫是為了幫助開發者提效的，但是在這種場景下開發者反而會抱怨改動樣式極大提高了他們的成本，并且大部分情況下還不得不這樣做。

再說回傳統 CSS 的問題，其實 tailwindcss 也解決了一部分，但是仍舊存在沒解決的點，比如說：

• 死代碼問題沒解決
• 樣式表的插入順序依舊有影響

以上說了那么多，其實對于我們使用 tailwindcss 而言，有利也有弊。它肯定是存在很好用的場景的，比如說寫個人的產品頁，或者說業務中樣式變化不頻繁的場景中，但是如果說需要業務中全量切換到 tailwindcss 的話，筆者肯定是持保留態度的。

對于 Atom CSS 來說，大家應該是不能否認它的優點的，但是我們是否有辦法在盡可能避免它的缺點的情況下又獲得它的優點呢?答案是有的，但是在講答案之前我想先來聊聊 CSS-in-JS。

CSS-in-JS

CSS-in-JS(下文以 CIJ 縮寫表示)核心就是在用 JS 寫 CSS，這同樣也是一個頗具爭議的技術方案。

在這個領域下有兩個庫比較流行，分別為：styled-components(下文以 sc 縮寫表示) 以及 Emotion。筆者目前已經用了一年多的 sc 了，來粗略談談它的優缺點。

我們先來了解下 sc 是怎么使用的。首先說下 sc 和 Emotion 的語法是趨于一致的，應該是為了 API 層面的統一吧，甚至前者還依賴了后者的一些包，以下是 sc 的常用寫法： 

const Button = styled.a` 
  display: inline-block; 
 
  ${props => props.primary && css` 
    background: white; 
    color: black; 
  `} 
` 
render( 
  <div> 
    <Button 
      href="https://github.com/styled-components/styled-components" 
      target="_blank" 
      rel="noopener" 
      primary 
    > 
      GitHub 
    </Button> 
 
    <Button as={Link} href="/docs"> 
      Documentation 
    </Button> 
  </div> 
) 

用法我們不多展開，有興趣的可以去官方看看，基本沒有學習成本的，主要是一些樣式組件上的使用。

另外 sc 并不是最終生成了內聯樣式，而是幫我們插入了 style 標簽。

優劣點

筆者用了一年多的 sc，感覺這種方案對于 React 來說是很香的。并且解決了我很討厭的傳統寫 CSS 的一些點，所以關于優劣點這段的講述會有點主觀。

首先 CSS-in-JS 這種方案不僅能讓我們完整使用到 CSS 的功能，而且還擴充了一些用法。比如說選擇器這塊，在 sc 中我們能通過選擇組件的方式來編寫樣式，如下代碼： 

const Button = styled.a` 
  ${Icon} { 
    color: green; 
  } 
` 

另外既然我們通過 JS 來管理 CSS 了，那么我們就可以充分享受 JS 帶來的工具鏈好處了。一旦項目中出現沒有使用到的樣式組件，那么 ESLint 就可以幫助我們找到那些死代碼并清除，這個功能對于大型項目來說還是能減少一部分代碼體積的。

除此之外，樣式污染、取名問題、自動添加前綴這些問題也很好的解決了。

除了以上這些，再來聊兩點不容易注意到的。

首先是動態切換主題。因為我們是通過 JS 來寫 CSS 了，那么我們就可以動態地控制樣式。如果你的項目有切換主題這種類似的大量動態 CSS 的需求，那么這個方案會是一個不錯的選擇。

還有個點是按需加載。因為我們是通過 JS 寫的 CSS，現階段打包基本都走的 code split，那么就可以實現 CSS 文件的按需加載，而不是傳統方式的一次性全部加載進來(當然也是可以優化的，只是沒那么方便)。

聊完了優點我們再來說說缺點。

第一個缺點很明顯，有學習成本，當然筆者覺得這個學習曲線還是平緩的。

運行時成本，sc 本身就有文件體積，加上還需要動態生成 CSS，那么這其中必定有性能上的損耗。項目越大影響的也會越大，如果你的項目對于性能有很高的要求，那么需要謹慎考慮使用。另外因為 CSS 動態生成，所以不能像傳統 CSS 一樣緩存 CSS 文件了。

代碼復用性和傳統寫 CSS 的方式沒啥兩樣。

最后點是代碼耦合問題。會有人覺得在大型項目中將 CSS 及 JS 寫在一起會增加維護成本，并且也不符合 CSS 需要分離開來想法。

Atom CSS 加上 CSS-in-JS 的縫合怪

看了上文，如果你覺得兩種方案都挺好的話，可以了解下 twin.macro，這個庫(還有別的競品)把這兩種方案融合了起來。 

import 'twin.macro' 
 
const Input = () => <input tw="border hover:border-black" /> 
const Input = tw.input`border hover:border-black` 

這種方案之上其實還有更好玩的方式，能幫助我們盡量取其精華而去其糟粕。

自動生成 Atom CSS 的 CSS-in-JS 方案

假如說我不僅想用 CSS-in-JS，還想把 Atom CSS 也給整上，但是又不想記 / 寫一大堆類名，我這個想法能實現么?

答案是有的。利用運行時的方式把單個樣式抽離出來，最后實現雖然我們寫的是 CSS-in-JS，但是最終呈現的是 Atom CSS 的樣子。

以 styletron 舉個例子，開發時候的代碼長這樣： 

import { styled } from "styletron-react"; 
 
export default () => { 
  // Create a styled component by passing 
  // an element name and a style object 
  const Anchor = styled("a", { 
    fontSize: "20px", 
    color: "red" 
  }); 
  return <Anchor href="/getting-started">Start!</Anchor>; 
}; 

實際編譯出來的時候長這樣： 

<html> 
  <head> 
    <style> 
      .foo { 
        font-size: 20px; 
      } 
      .bar { 
        color: red; 
      } 
    </style> 
  </head> 
  <body> 
    <a href="/getting-started" class="foo bar">Start!</a> 
  </body> 
</html> 

這樣的方式就能很好地享受到兩種方案帶來的好處了。但是這類方案筆者找了些競品，覺得還沒有前兩者方案來的流行，大家了解一下即可。另外這種方式帶來的運行時成本應該會更大，也許可以配套打包工具在本地先做一次預編譯(一個不成熟的想法，說錯勿噴)?

總結

說了那么多方案，可能讀者會有疑問，那么我到底該用啥?這里筆者說下自己的想法。

首先對于 sc 來說，筆者覺得很香，在項目中大范圍用起來未嘗不可，當然我們還可以搭配著 Atom CSS 一起來寫通用樣式。

對于 Atom CSS，筆者個人認為不適合項目中大規模使用，起碼在我們公司內部不會是一個好方案，畢竟視覺真的會來動某些通用樣式。