做者 | Chris Coyier譯者 | 王強編輯 | Yoniecss
有些人極爲討厭 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/
活動推薦GMTC 全球大前端技術大會首次落地華南,走入大灣區深圳。
往屆咱們請到了來自 Google、Twitter、Instagram、阿里、騰訊、字節跳動、百度、京東、美團等國內外一線公司的頂級前端專家,分享了關於小程序、Flutter、Node、RN、前端框架、前端安全、前端工程化、移動 AI 等 50 多個熱門技術專題。目前深圳站正式啓動,7 折最低價售票通道已經開啓,詳細請諮詢:13269078023(同微信)。