Facebook 那堆亂碼 class name，其實藏著一套現在人人搶著抄的系統
TL;DR
- StyleX 是 Meta 內部用來寫 CSS 的系統，Facebook、Instagram、WhatsApp、Threads 全部跑在上面，二〇二三年底開源
- 你在 Facebook 上看到的那些
x1i10hfl亂碼 class，不是他們自己版本的 Tailwind，是編譯後的產物 - 核心做法：每一組「屬性＋值」單獨生成一個 class，全站去重，所以 CSS 檔案大小會隨著專案變大而趨近持平
- 三年前 Syntax.fm 做過一集，沒什麼人理；今年突然變成顯學，理由只有一個字：agent
- Jared Palmer 的判斷是，人手寫 Tailwind 還是比較舒服，但既然現在人已經很少手寫了，權衡就變了
- Linear 已經搬超過一半，Aiden Bai 把個人網站搬過去，首次內容繪製快兩成、CSS 體積少一半
- 缺點也很實在：手寫超醜、巢狀選擇器難搞、新的 CSS 特性要等支援
- 這集最有意思的一句話是 Scott 說的：「這個東西不是給我寫的，但看起來是給 agent 寫的。」
先講一下這集的來歷。Syntax.fm 是 Wes Bos 跟 Scott Tolinski 兩個全端工程師主持的網頁開發 Podcast，一週兩集，主題從 CSS、JavaScript 框架到伺服器什麼都聊，是英文圈開發者社群裡黏著度很高的一個節目（順帶一提，這節目後來被錯誤追蹤工具公司 Sentry 收下了，但兩位主持人風格完全沒變，一樣愛吵架）。這集是二〇二六年九月二日播出的第 1035 集，題目叫「Why everyone is moving to StyleX?」。Wes 是 Tailwind 派、Scott 是 CSS Modules 派，兩個人在這集裡的角色分配非常清楚：Wes 負責講 StyleX 有多合理，Scott 負責一邊承認它合理一邊喊「但我看到那個語法就想吐」。
那些亂碼 class 到底是怎麼來的
如果你 inspect 過 Facebook 的網頁，你會看到每個元素上掛著二三十個看不懂的 class name。多數人的第一直覺是「哦，這就是他們內部版的 Tailwind」。不是這樣。
StyleX 的運作是這樣：你在 JavaScript 裡用物件的形式寫樣式，字體大小、行高、顏色都寫進去，然後有一個編譯階段（build time，程式碼交給瀏覽器之前的處理步驟）把它整包掃過，把每一組「屬性加值」拆成一個獨立的 atomic class（原子化類別，一個 class 只負責一件事）。
關鍵在於全站去重。padding-top: 0 這件事，Meta 全部產品加起來可能寫了三十萬次，但編譯完之後全世界只會存在一個 class 對應它。所以你才會看到一個元素身上掛二三十個 class，因為每個 class 只做一件事。
這跟 Svelte 或 CSS Modules 那種「scoped CSS」的做法不一樣。那些工具是把一整組樣式包成一個 class，例如 .podcast-card 裡面含邊框、背景、圓角、陰影。StyleX 是把這四件事拆成四個 class，然後全站共用這四個。
Meta 官方公布的數字是導入之後 CSS 體積降了八成。這個邏輯有點反直覺但很好懂：傳統寫法下，你的 CSS 檔案會隨著功能增加線性膨脹；原子化之後，因為可用的屬性值組合是有限的，檔案大小會慢慢趨近一條水平線。專案越大，這個差距越誇張。
為什麼是現在
Wes 提到一件挺尷尬的事：他們三年前就做過一集 StyleX，當時沒什麼迴響。今年突然所有人都在講。
觸發點是 Jared Palmer（Turborepo 創辦人）的一則推文。他的原話大意是：搞了十年 atomic CSS 框架，從各種方案一路到 Tailwind，他現在認為 StyleX 對 agent 來說是更好的選擇，因為 StyleX 的約束會讓程式碼庫長大之後更一致、更正確。他還補了一句很誠實的話：如果是人在寫，Tailwind 還是贏；但我們已經不太自己寫了，所以權衡改變了。
Wes 對這句話的反應是「我覺得他可能是對的」，Scott 的反應是「我不想承認但我也覺得他是對的」。
這裡有一個很多人沒注意到的轉折。Tailwind 之所以在 AI 時代先贏一輪，是因為它跟 markup 寫在同一個地方，模型看到 HTML 就看到樣式，不用在兩個檔案之間跳來跳去猜對應關係。這是「同地共置」帶來的優勢。
但 StyleX 提供的是另一種東西：型別。整套樣式是 typed 的，你的 design system 可以直接編碼成型別限制，什麼能用、什麼不能用，編輯器當場就會告訴你。Wes 在節目裡直接開了 playground 示範，打一個點，自動補全就把所有已定義的樣式列出來；再打一個點，所有可用的 CSS 屬性也列出來。
這件事對人來說是「方便」，對 AI agent 來說是「防呆」。Scott 講了一個大家都遇過的狀況：AI 常常憑訓練資料的記憶，寫出一個你專案裡根本不存在的 class name，如果沒有 lint 擋著，這東西就這樣進了 codebase，然後畫面就少了一塊樣式。型別系統會直接讓這種事寫不出來。
之前在Design Engineer 正在崛起那篇聊過，AI 生出來的介面像郊區建案，遠看都是房子，住進去才發現車庫開不了門。StyleX 想解的是同一個問題的另一半：與其事後檢查，不如一開始就讓它寫不出錯的東西。
真的有比較快嗎
節目裡引了兩個實測。
Linear 的 Adam Hutchison 說他們已經把超過五成的程式碼搬到 StyleX，得到的好處是元件組合的控制力變強、什麼能被覆寫變得清楚，另外 render 效能也改善了。這點值得展開一下：傳統 CSS 有層疊（cascade），瀏覽器要算出 margin: 0 跟 margin-bottom: 4 誰蓋過誰。原子化之後每個 class 各管各的，沒有互相覆蓋的計算，瀏覽器少做事。
另一個是 Aiden Bai，做過 React Scan、million.js 這些效能工具的人。他把個人網站從 Tailwind 搬到 StyleX，數字是首次內容繪製（FCP，畫面上第一個東西出現的時間）快兩成、最大內容繪製（LCP）快百分之七、CSS 體積少一半。
Wes 自己也很老實地補了一句：可能有人會說「有 gzip 啊，重複字串壓縮完根本不佔空間」。這話對一半。傳輸量確實不會差太多，但瀏覽器解析 CSS 是實打實要花時間的，而且解析是在解壓縮之後才發生。話說回來，他也承認大部分網站的效能瓶頸根本不在 CSS，這幾個百分點對絕大多數人來說沒有感覺。
難看，真的很難看
這集最有娛樂性的部分是 Scott 的內心戲。他一開始就說：「沒有什麼比在 JavaScript 物件裡寫 CSS 更讓我噁心的了。」然後整集都在跟自己打架。
他的抱怨其實都很具體，不是純粹的美感問題：
巢狀選擇器。你有一個 .podcast-heading，裡面有個 <span> 包著集數編號。用一般 CSS 你就是在裡面巢狀一個 span 選擇器，兩行搞定。用 StyleX 你得為那個 span 另外定義一個完整的樣式物件。當一個頁面裡有幾十個這種小地方，寫起來會很煩。
修改 CSS 變數。原生 CSS 就是 var(--text)，一眼看完。在 StyleX 裡你要包一個 function、做字串插值、從物件裡撈屬性出來，程式碼量差好幾倍。
新的 CSS 特性。像 sibling index 這種比較新的東西，或是複雜的 media query 組合，寫在物件語法裡都很痛苦。Wes 的建議很務實：碰到這種情況，就開一個 .css 檔直接寫原生 CSS，不用硬要把所有東西塞進同一套抽象裡。他說他用 Tailwind 也是這樣，「與其寫一個怪異的 plugin，不如直接寫幾行 CSS，這不算輸」。
但 Scott 最後給出的結論才是整集的重點。他說：「這個介面不是給我用的（他還特別強調是全大寫的『不是給我用的』），但它看起來是給 agent 用的。」
我的看法：DX 的定義正在被改寫
這集表面在吵 CSS 方案，底下真正在講的是另一件事。
過去十幾年，開發者體驗（DX）這個詞的意思基本上是「人寫起來爽不爽、讀起來順不順」。Tailwind 贏在這裡，Svelte 贏在這裡，CSS Modules 也贏在這裡。Scott 對 StyleX 的所有抗拒，全部來自這個舊定義。
但當程式碼的主要作者從人變成模型，DX 的評分標準就換了一套。現在值錢的是確定性：這個 class 存不存在，編譯器知道；這個值合不合法，型別知道；這兩組樣式合併的結果是什麼，JavaScript 的物件合併規則說了算，不用去猜 CSS 特異性（specificity）跟宣告順序。
換句話說，約束的價值超過了表達力的價值。以前一套工具太死板是缺點，因為人被綁住會不爽；現在死板變成優點，因為模型不會不爽，模型只會在沒有護欄的地方失控。之前在一週合併六十個 PR，然後整個專案爛掉那篇提過的問題，本質是一樣的：產出速度暴增之後，人工把關的環節先崩，能撐住的只剩機器可驗證的規則。
Scott 有一句吐槽講得很直白：AI 對 CSS 就是很爛，它每次都是「當下想到什麼就加什麼」，久了就是一坨沒人維護得動的東西。這個觀察我完全同意。我自己讓 agent 改樣式的經驗是，它很少改壞邏輯，但很常留下一堆重複、互相覆蓋、誰也不敢刪的規則。
那你該不該搬
節目裡也提到替代方案。Panda CSS 是理念很接近的東西，一樣是編譯期原子化，但它同時支援 tagged template 語法（讓你用接近原生 CSS 的寫法）跟物件語法，等於兩邊都要。Wes 說如果你是從零開始的專案，在考慮 StyleX 的同時應該把 Panda 一起看一下。Scott 補了一句「而且他們的品牌好看多了，一邊是熊貓，一邊是企業感的 logo」，這個標準我居然覺得挺有道理。
我的實務判斷是這樣：
既有專案不要為了搬而搬。Linear 那種等級的搬遷花了超過一千個 PR，你要先確定你的痛點真的是 CSS 漂移，而不是別的東西。如果你的專案只有二十個頁面，你省下來的那點 CSS 體積不會改變任何事。
新專案、而且主要靠 agent 寫的，值得認真試。特別是你已經有一套設計系統要守，需要一個編譯器幫你擋住所有偏離的情況。
判斷方式很簡單：去看你最近三個月的 CSS，如果裡面有一堆 .card、.card-new、.card-v2、.card-final，那你需要的是約束，不是更好寫的語法。
Wes 在最後開了個玩笑，說下一集 Scott 就會完全變成 StyleX 信徒然後講個不停。以我聽這節目的經驗，這個預測的準確率大概是九成。
順帶一提，如果你是那種堅持自己手刻 CSS 的人，這集不會說服你，也不需要說服你。工具的選擇從來就跟「誰在用」高度綁定，你自己寫，你就選你順手的。只是市場的重心正在移動，而移動的方向對手寫派不太友善。
我平常也在寫這類產業觀察跟工具評估，都放在 wilsonhuang.xyz，覺得有用的話可以訂閱一下，新的文章會直接送到你信箱。
Sources:
推薦閱讀
喜歡這篇文章嗎？
訂閱電子報，每週收到精選技術文章與產業洞察，直送你的信箱。
💌 隨時可以取消訂閱，不會收到垃圾郵件