淺談 Atomic CSS 的發展背景與 Tailwind CSS - Huli

[utterances-bot]

淺談 Atomic CSS 的發展背景與 Tailwind CSS - Huli

https://blog.huli.tw/2022/05/23/atomic-css-and-tailwind-css/

[aszx87410]

看完這篇之後的感想是？

[Lauviah0622]

看到 Tools, not rule 這部份的時候，想到 React 剛出來也是一堆人覺得噁心，但最後真香定律還是獲勝了

[chienweiluo]

拜讀～鼓掌給讚！Atomic還有帶出一個我覺得超重要的點是對design token 的優勢, 這對後期Design System還是訂製化甚至跨端或都是很好的架構！

[goodjack]

回報 Typo~ common pratice -> common practice

[aszx87410]

@goodjack 已修正，感謝

[MrOrz]

看完這篇之後的感想是？

拜讀大大的文章，像是在快轉過去近 10 年的 CSS 方法論論辯，真的很精彩 m( )m

文中對 atomic CSS "page agnostic" 的特性是我之前沒有想過的。我之前對 atomic CSS 的理解是，想要透過讓每個 CSS declaration 都只包含最少的 CSS property（一個 class 一個 property 的 “atomic” class），解決傳統 CSS 「一個網站的樣式裡訂了幾百次 font-size」、「某兩個區塊部分樣式重疊，但還是不太一樣，那訂一個新的 class 吧」等等的 style bloat 問題，以及「這個帶有樣式的區塊我真的不知道該叫什麼名字但還是得取一個 class」的命名問題。

Style 變成 local scope、或避免 class name collision，比較像是 CSS module 與 OOCSS/SMACSS/BEM 等 naming convention 想要解決的問題。相對的，CSS module 與 naming convention 仍然有 code bloat 與 naming 的 issue，畢竟這兩個 solution 不是針對這兩個 issue 設計的。

當一個傳統 CSS 專案想要再後來才導入 atomic CSS 如 tailwind，就要擔心自己現有的 class 是不是好死不死跟 tailwind 撞名，這個 global 互撞的感覺令人熟悉 (?)，是我之前不會把 Atomic CSS 與 local style 聯想在一起的原因。

CSS-in-JS 如 styled-component 對我來說，除了 local scope 之外，帶來最大的價值大概是能用管理 JS component 的方式來管理各個帶有樣式的區塊 —— 除了可以跟著 JS 一起 import 與複用，在修改時想查看一個 styled-component 在哪裡被用到，編輯器內建 Intellisense 或類似的東西都能幫我們找到，無需使用可能撈出 false positive 的文字搜尋。開發者手上能用來管理 JS dependency 的工具多又方便，支援度遠比 CSS module compose、或 CSS preprocessor 的 @include/@extend 高太多。

不過，CSS-in-JS 一樣有「某兩個區塊部分樣式重疊，但還是不太一樣，那訂一個新的 component 吧」的 code bloat 問題，以及需要幫無名區塊硬想一個 component 名字的困擾。如果開發時，這兩個痛點帶來的困擾遠大於其他東西的話，那就該讓專門解這兩個 issue 的 Atomic CSS 進場大顯身手呢。

[chienweiluo]

看完這篇之後的感想是？

拜讀大大的文章，像是在快轉過去近 10 年的 CSS 方法論論辯，真的很精彩 m( )m

文中對 atomic CSS "page agnostic" 的特性是我之前沒有想過的。我之前對 atomic CSS 的理解是，想要透過讓每個 CSS declaration 都只包含最少的 CSS property（一個 class 一個 property 的 “atomic” class），解決傳統 CSS 「一個網站的樣式裡訂了幾百次 font-size」、「某兩個區塊部分樣式重疊，但還是不太一樣，那訂一個新的 class 吧」等等的 style bloat 問題，以及「這個帶有樣式的區塊我真的不知道該叫什麼名字但還是得取一個 class」的命名問題。

Style 變成 local scope、或避免 class name collision，比較像是 CSS module 與 OOCSS/SMACSS/BEM 等 naming convention 想要解決的問題。相對的，CSS module 與 naming convention 仍然有 code bloat 與 naming 的 issue，畢竟這兩個 solution 不是針對這兩個 issue 設計的。

當一個傳統 CSS 專案想要再後來才導入 atomic CSS 如 tailwind，就要擔心自己現有的 class 是不是好死不死跟 tailwind 撞名，這個 global 互撞的感覺令人熟悉 (?)，是我之前不會把 Atomic CSS 與 local style 聯想在一起的原因。

CSS-in-JS 如 styled-component 對我來說，除了 local scope 之外，帶來最大的價值大概是能用管理 JS component 的方式來管理各個帶有樣式的區塊 —— 除了可以跟著 JS 一起 import 與複用，在修改時想查看一個 styled-component 在哪裡被用到，編輯器內建 Intellisense 或類似的東西都能幫我們找到，無需使用可能撈出 false positive 的文字搜尋。開發者手上能用來管理 JS dependency 的工具多又方便，支援度遠比 CSS module compose、或 CSS preprocessor 的 @include/@extend 高太多。

不過，CSS-in-JS 一樣有「某兩個區塊部分樣式重疊，但還是不太一樣，那訂一個新的 component 吧」的 code bloat 問題，以及需要幫無名區塊硬想一個 component 名字的困擾。如果開發時，這兩個痛點帶來的困擾遠大於其他東西的話，那就該讓專門解這兩個 issue 的 Atomic CSS 進場大顯身手呢。

剛好看到樓上的留言好用心也一起多回一下，我理解 atomic 是一種組裝樣式的方法，css-in-js是提供樣式動態能力的方式，也就是css module 純css 一樣也可以實現atomic css. 所以總覺得你可以看一下styled-system，它可以說是 atomic css-in-js的實現，我覺得這兩個是共同的趨勢，styled system很超前的在做這件事了，說不定可以幫助你的問題。如果我理解錯了也可以交流一下😅

[aszx87410]

@MrOrz 其實從文章中可以看出，Atomic CSS 一開始被提出時，完全沒提到命名的問題，節省命名的困擾在我看來比較像是剛好出現的附加價值，而非 Atomic CSS 主要的價值

在 CSS-in-JS 也可以解掉 scope 的問題後，Atomic CSS 獨有的價值就是 code bloat，而且這個 code bloat 不單單只是「某兩個區塊部分樣式重疊，但還是不太一樣，那訂一個新的 component 吧」，而是「就算兩個 component 意義上完全不同，只是剛好文字顏色都是紅色」，也會造成 code bloat 的問題

舉例來說，你在傳統的寫法上每次要用到 display: flex 的地方，最後產生的 CSS 都會有一行 display: flex，你有五個元素都有用到，就會有五條 display:flex 出現，這個其實我們會覺得再正常不過，但透過 Atomic CSS，可以讓最後只出現一個 display:flex，大幅減少了 CSS 的程式碼

而底下 @chienweiluo 提的那套在我看來其實跟 Atomic CSS-in-JS 沒什麼關係（或更精確來說，參考的面向不同）。

我文章中提及的臉書提出的 Atomic CSS-in-JS，想解決的問題是：「CSS-in-JS 可以拿來解 scope 已經很好用了，但唯一的缺點是產生的 CSS 還是會重複，沒辦法像 Atomic CSS 那樣」，於是他們就提出了：「那如果我可以照常寫 CSS-in-JS，但是產生的 CSS 卻長得像 Atomic CSS 呢？」，就有了這張截圖：

可以看見左邊他照常寫，可是最後產生出來的 style 卻像是 Atomic CSS 一樣，一個規則就對應到一個 class。這樣做的好處就是開發者不需要去熟悉 Atomic CSS 系統獨有的簡寫規則，而是可以像往常一樣寫 CSS，卻依然享受到 Atomic CSS 能夠降低檔案大小的好處

而 styled system 它參考 Atomic CSS 的地方不在 local scope，也不在檔案大小，而是我文章中最早提及的「限制（constraints）」。還記得最早的時候 Atomic CSS 是純靜態的嗎？透過靜態的 class name 來限制元件可以用的 style，藉此約束其 UI。

而 styled system 就是從這個概念發展出去的，你可以事先定義好一堆規則，然後你的 styled component 基本上就只能用這些規則去寫樣式，這也是我認為它唯一有參考到 Atomic CSS 的地方。我不會稱這個是 Atomic CSS-in-JS，因為它最後產生出來的 style 還是跟傳統的 CSS-in-JS 一樣，有著重複的規則

[chienweiluo]

學習了 讚讚, (很怕用詞又出錯)不過釐清一下我指的atomic是指atomic styling, 可能不是很清楚地像回覆中指的 Atomic Classname, 是說 styled-system可 以run 在"支持Atomic Classname的css-in-js library" 以實現Huli講的"去除重複的規則"(Atomic css-in-js), 確實是參考的點不同, 不過在開發體驗(MrOrz的最後一段)跟概念上我是覺得滿符合atomic 的 XD