每日最新頭條.有趣資訊

CSS-in-JS是惡魔還是天使?

作者 | Chris Coyier

譯者 | 王強

編輯 | Yonie

有些人極為討厭 CSS-in-JS,單單提起這個名字都會讓他們反感,總之就是拒絕二字。他們認為樣式不屬於 JavaScript,而是屬於 CSS,並且 CSS 有著很長的歷史,瀏覽器支持非常完善。關注點必須分離,其他路子都走錯了,我們要以史為鑒(比如標簽等)。

有些人非常喜歡 CSS-in-JS。他們看到模板和功能並存的理念和大多數的 JavaScript 框架都非常成功,所以包裝在樣式裡似乎就是順其自然。Vue 的單文件組件就是一個例子。

Brent Jackson 列舉了一些 CSS-in-JS 能做和不能做的事情:

CSS-in-JS 能做什麽:

讓你用 JavaScript 語法編寫 CSS

組件和樣式共用

利用原生 JS 語法功能

利用 JS 生態系統

CSS-in-JS 沒法讓你了解:

如何將樣式應用於 DOM

繼承如何工作

CSS 屬性如何工作

CSS 布局如何工作

CSS-in-JS 並不能減輕你學習 CSS 的負擔,大多數情況下就是如此。

CSS-in-JS 是惡魔還是天使?

我聽過很多對 CSS-in-JS 的排斥言論,諸如“你用 CSS-in-JS 是因為你不懂 CSS”或者“你們這樣做是因為你害怕級聯。我已經知道如何定位 CSS 了。“但這些言論只是在挑事而已。

Lara buns 的那篇“沒有 Web 的 Web 世界”寫的很好,其中就提到了 React 和 CSS-in-JS:

我討厭 React,因為默認情況下 CSS-in-JS 方法需要你編寫完全自包含的組件,而不是從宏觀層面構建網站的 UI。

不是說你用了 React 就得用 CSS-in-JS,但這種做法很流行,上面這段評價也很公正有趣。如果你什麽東西都要打包,難道不是在引入更多不一致的風險嗎?

我一直都是 CSS 模塊的粉絲,因為它就像 CSS-in-JS 一樣簡單,而且和 SASS 並用可以保證一致性。但人們使用它時也很容易陷入太多一次性使用的陷阱中。

這些只會用一次的代碼可以拋棄,可以分離,一切都很平衡。

Laura 還說她喜歡 CSS-in-JS 方法,它提供了一些強大的功能和靈活性:

我喜歡 CSS-in-JS,因為它提供了足夠的抽象,讓你既能用通用選擇器之類的技巧,同時也能充分利用 JS 來做容器查詢之類的東西。

Martin Hofmann 創建了一個網站,用一個很小的“警報組件”來客觀地對比 BEM 與 Emotion。BEM 有一些優點,特別是不需要任何工具,並且可以輕鬆地與任何 Web 項目共享。但 Emotion 方法在很多方面都比較乾淨,看起來更容易處理。

我希望有更多這種客觀的技術比較,公正地列出每項技術的優勢和代價。

Scott Jehl 的一篇文章討論了異步加載 CSS。文章開頭寫到:

我們可以用一種不會拖累頁面渲染的方法加載 CSS,大幅提升頁面性能和適應性。

值得一提的是 CSS-in-JS 方法天然就有這種能力,因為樣式被捆綁到了 JavaScript 中。當然這種做法需要付出性能代價,但是如果我們消除一些阻塞渲染的障礙就能減輕一些代價。起碼這種方法值得多用一些數據。

我不覺得 CSS-in-JS 就一定提高了行業的門檻。我們並沒有強行排除 CSS,強迫大家用別的語言。這種方法適合某些項目,適用於特定規模。

我覺得以下情況下你應該考慮一下 CSS-in-JS:

你正在開發一個有大量組件的 JavaScript 項目。

你要把模板、功能和數據查詢做在一起。

你認為利用這種方法的同時不會影響用戶體驗。

你的團隊喜歡這種技術,不會因此萌生退意。

Max Stoiber 寫的文章介紹了這種方法給他帶來的信心和為他節省的時間。但他也認為這種方法隻適合 JavaScript 框架應用程序。

如果你使用 JavaScript 框架來構建包含組件的 Web 應用程序,那麽 CSS-in-JS 可能非常適合你的需求。如果你的團隊成員都具備基本的 JavaScript 能力那就最好不過了。

https://css-tricks.com/the-differing-perspectives-on-css-in-js/

點個在看少個 bug

獲得更多的PTT最新消息
按讚加入粉絲團