摘要：原文地址原文作者譯文出自掘金翻譯計劃譯者校對者統一樣式語言在過去幾年中，我們見證了的興起，尤其是在社區。根本上來說，純粹用于只是一個命名規范，它要求樣式的類名要遵守的模式。

原文地址：A Unified Styling Language

原文作者：Mark Dalgleish

譯文出自：掘金翻譯計劃

譯者：ZhangFe

校對者：JackGit,yifili09

在過去幾年中，我們見證了 CSS-in-JS 的興起，尤其是在 React 社區。當然，它也飽含爭議。很多人，尤其是那些已經對 CSS 非常熟悉的人都表示難以置信。

"為什么有人要在 JS 中寫 CSS？
這簡直是一個可怕的想法！
但愿他們學過 CSS !"

如果這就是你的反應，那么請繼續讀下去。我們來看看到底為什么在 JavaScript 中編寫樣式并不是一個可怕的想法，并且為什么我認為你應該關注這個快速發展的領域。

React 社區經常被 CSS 社區誤解，反之亦然。對我來說這很有趣，因為我經常混跡于這兩個社區。

我從九十年代后期開始學習 HTML，并且從基于表格布局的黑暗時代以來就一直使用 CSS。受 CSS Zen Garden 啟發，我是最早一批將現有代碼向 語義化標簽 和級聯樣式表遷移的人。不久之后，我開始專注于前后端分離，使用非侵入式 JavaScript 和客戶端的交互來裝飾服務端渲染的 HTML。圍繞這些做法有一個小型且充滿活力的社區，并且我們成為第一代嘗試給瀏覽器平臺應有尊重的前端開發者。

伴隨這樣的背景，你可能會認為我會強烈反對 React 的 HTML-in-JS 模式，它似乎違背了我們所堅持的原則，但實際上恰恰相反。根據我的經驗，React 的組件模型加上服務端渲染的能力，最終給我們提供了一種構建大規模復雜單頁應用的方式，從而使我們能夠將快速，可訪問，逐漸增強的應用推送給我們的用戶。在 SEEK 上我們就利用了這種能力，這是我們的旗艦產品，它是 React 單頁應用程序，當 JavaScript 被禁用時我們的核心搜索流程依然可用，因為我們通過在服務器端運行同構的 JavaScript 代碼來完成到傳統的網站優雅降級。

所以，也請考慮一下我拋出的從一個社區到另一個社區的橄欖枝。讓我們一起嘗試理解這個轉變。它可能不完美，它可能不是你計劃在產品中使用的東西，它可能對你不是很有說服力，但是至少值得你嘗試思考一下。

如果你熟悉我最近做的與 React 以及 CSS 模塊相關的工作，當看到我維護 CSS-in-JS 時你可能會很驚訝。

畢竟，通常那些希望有局部樣式但是又不希望在 JS 中寫 CSS 的開發者會選擇使用 CSS 模塊。事實上，甚至我自己在工作中也還沒用到 CSS-in-JS。

盡管如此，我任然對 CSS-in-JS 社區保持濃厚的興趣，對他們不斷提出的創意保持密切關注。不僅如此，我認為更廣泛的 CSS 社區對它也應該很感興趣

原因是什么呢?

為了更清楚地了解為什么人們選擇在 JavaScript 中編寫他們的樣式，我們將重點關注采用這種方式時帶來的實際好處。

我把它分為五個方面:

局部樣式

關鍵 CSS

智能優化

打包管理

在非瀏覽器環境下的樣式

讓我們進一步的細分并且仔細看看 CSS-in-JS 提供的每一點優勢。

想要在大規模項目中高效的構建 CSS 是非常困難的。當加入一個現有的長期運行的項目時，通常我們會發現 CSS 是系統中最復雜的部分。

為了解決這個問題，CSS 社區已經投入了巨大的努力，通過 Nicole Sullivan 的 OOCSS 和 Jonathan Snook 的 SMACSS 都可以使我們的樣式更好維護，不過 Yandex 開發的 BEM 更流行一些。

根本上來說，BEM （純粹用于 CSS）只是一個命名規范，它要求樣式的類名要遵守 .Block__element--modifier 的模式。在任何使用 BEM 風格的代碼庫中，開發人員必須始終遵守 BEM 的規則。當嚴格遵守時，BEM 的效果很好，但是為什么這些如同作用域一般基礎的功能，卻只使用單純的命名規范來限制呢？

無論是否有明確表示，大多數 CSS-in-JS 類庫都遵循 BEM 的思路，它們嘗試將樣式定位到單個 UI 組件，只不過用了完全不同的實現方式。

那么在實際編寫代碼時什么樣的呢？當使用 Sunil Pai 開發的 glamor 時，代碼看起來像下面這樣：

import { css } from "glamor"
const title = css({
  fontSize: "1.8em",
  fontFamily: "Comic Sans MS",
  color: "blue"
})
console.log(title)
// → "css-1pyvz"

你可能會注意到代碼中沒有 CSS 的類名。因為它不再是一個指向定義在項目其他位置 class 的硬編碼，而是由我們的庫自動生成的。我們不必再擔心全局作用域內的選擇器沖突，這也意味著我們不再需要替他們添加前綴了。

這個選擇器的作用域與周圍代碼的作用域一致。如果你希望在你應用的其他地方使用這個規則，你就需要將它改寫成一個 JavaScript 模塊并且在需要使用的地方引用它。就保持代碼庫的可維護性而言，它是非常強大的，它確保了任何給定的樣式都可以像其他代碼一樣容易追蹤來源。

通過從僅僅是命名約定到默認強制局部樣式的轉變，我們已經提高了我們樣式質量的基準線。BEM 已經烙在里面了，而不再是一個可選項。

—

在繼續之前，我要說明至關重要的一點。

它生成的是真正的級聯樣式，而不是內聯樣式

大多數早期的 CSS-in-JS 庫都是將樣式直接添加到每個元素上，但是這個模式有個嚴重的缺點，"styles" 屬性并不能做到 CSS 可以做到的每件事。大多數新的庫不再關注于動態樣式表，而是在運行時在全局樣式中插入和刪除規則。

舉個例子，讓我們看看 Oleg Slobodskoi 開發的 JSS，這是最早的 CSS-in-JS 庫之一，并且它生成的是真實的 CSS。

當使用 JSS 時，你可以使用標準的 CSS 特性，比如 hover 和媒體查詢，它們會映射到相應的 CSS 規則。

const styles = {
  button: {
    padding: "10px",
    "&:hover": {
      background: "blue"
    }
  },
  "@media (min-width: 1024px)": {
    button: {
      padding: "20px"
    }
  }
}

一旦你將這些樣式插入到文檔中，你就可以使用那些自動生成的類名。

const { classes } = jss.createStyleSheet(styles).attach()

無論你是使用一個完整的框架，還是簡單的使用 innerHTML，你都可以在 JavaScript 中使用這些生成的 class，而不是硬編碼你的 class 字符串。

document.body.innerHTML = `
  
Hello World!
`

多帶帶使用這種方式管理樣式并沒有多大的優勢，它通常和一些組件庫搭配使用。因此，通常可以找到用于最流行庫的綁定方案。例如，JSS 可以通過 react-jss 的幫助輕松地綁定到 React 組件上，在管理生命周期的同時，它可以幫你給每個組件插入一小段樣式。

import injectSheet from "react-jss"
const Button = ({ classes, children }) => (
  
    
      {children}
    
  
)
export default injectSheet(styles)(Button)

通過將我們的樣式集中到組件上，可以將他們和代碼跟緊密的結合，這不就是 BEM 的思想么？所以 CSS-in-JS 社區的很多人覺得在所有的樣式綁定樣板中，提取、命名和復用組件的重要性都丟失了。

隨著 Glen Maddern 和 Max Stoiber 提出了 styled-components 的概念，出現了一個新的思考這個問題的方式。

我們直接創建組件，而不是創建樣式然后手動地將他們綁定到組件上。

import styled from "styled-components"

const Title = styled.h1`
  font-family: Comic Sans MS;
  color: blue;
`

使用這些樣式時，我們不會將 class 添加到存在的元素上，而是簡單地渲染這些被生成的組件。

雖然 styled-components 通過模板字面量的方式使用了傳統的 CSS 語法，但是有人更喜歡使用數據結構。來自 PayPal 的 Kent C. Dodds 開發的 Glamorous 是一個值得關注的替代方案。

Glamorous 和 styled-components 一樣提供了組件優先的 API，但是他的方案是使用對象而不是字符串，這樣就無需在庫中引入一個 CSS 解析器，可以降低庫的大小并提高性能。

import glamorous from "glamorous"

const Title = glamorous.h1({
  fontFamily: "Comic Sans MS",
  color: "blue"
})

無論你使用什么語法描述你的樣式，他們不再僅僅是組件的一部分，他們和組件已經無法分離。當使用一個像 React 這樣的庫時，組件是基本構建塊，并且現在我們的樣式也成了構建這個架構的核心部分。如果我們將我們應用程序中的所有內容都描述為組件，那么為什么我們的樣式不行呢？

—

考慮到我們之前介紹的對系統做出改變的意義，對于那些有豐富 BEM 開發經驗的工程師來說，這一切看起來似乎是一個很小的提升。事實上，CSS 模塊讓你在不用放棄 CSS 工具生態系統的同時獲得了這些提升。很多項目堅持使用 CSS 模塊還有一個原因，他們發現 CSS 模塊充分解決了編寫大規模 CSS 的問題，并且可以保持編寫常規 CSS 時的習慣。

然而，當我們開始在這些基本概念上構建時，事情開始變得更有趣。

在文檔頭部內聯關鍵樣式已經成為一種比較新的最佳實踐，通過僅提供當前頁面所需的樣式可以提高首屏時間。這與我們常用的樣式加載方式形成了鮮明對比，之前我們通常會強制瀏覽器在渲染之前為應用下載所有的樣式。

雖然有工具可以用于提取和內聯關鍵 CSS，比如 Addy Osmani 的 critical，但是他們無法從根本上改變關鍵 CSS 難以維護和難以自動化的事實。這是一個棘手的、可選的性能優化，所以大部分項目似乎放棄了這一步。

CSS-in-JS 則是一個完全不同的故事。

當你的應用使用服務端渲染時，提取關鍵 CSS 不僅僅是一個優化，從根本上來說，服務器端的 CSS-in-JS 是使用關鍵 CSS 的首要工作。

舉個例子，當使用 Khan Academy 開發的 Aphrodite 給元素添加 class 時，可以通過內聯調用它的 css 函數來跟蹤在這次渲染過程中使用的樣式。

import { StyleSheet, css } from "aphrodite"
const styles = StyleSheet.create({
  title: { ... }
})
const Heading = ({ children }) => (
  
{ children }
)

即便你所有的樣式都是在 JavaScript 中定義的，你也可以很輕松的從當前頁面中提取所有的樣式并生成一個 CSS 字符串，在執行服務端渲染時將它們插入文檔的頭部。

import { StyleSheetServer } from "aphrodite";

const { html, css } = StyleSheetServer.renderStatic(() => {
  return ReactDOMServer.renderToString();
});

你可以像這樣渲染你的關鍵 CSS：

const criticalCSS = `
  
`;

如果你看過 React 的服務端渲染模型，你可能會發現這個模式非常熟悉。在 React 中，你的組件在 JavaScript 中定義他們的標記，但可以在服務器端渲染成常規的 HTML 字符串。

如果你使用漸進增強的方式構建你的應用，盡管全部使用 JavaScript 編寫，但也有可能在客戶端根本就不需要 JavaScript

無論用哪種方式，客戶端 JavaScript bundle 都要包含啟動單頁應用所需的代碼，它能讓頁面瞬間活起來，并與此同時開始瀏覽器中進行渲染。

由于在服務器上渲染 HTML 和 CSS 是同時進行的，就像前面的例子所示， Aphrodite 這樣的庫通常會以一個函數調用的方式幫助我們流式生成關鍵 CSS 和服務端渲染的 HTML。現在，我們可以用類似的方式將我們的 React 組件渲染成靜態 HTML。

const appHtml = `
  

    ${html}
  
`

通過在服務器端使用 CSS-in-JS，我們的單頁應用不僅可以脫離 JavaScript 工作，它甚至可以加載的更快。

與我們選擇器的作用域一樣，渲染關鍵 CSS 的最佳實踐如今已經烙在里面了，而不是一個可選項。

我們最近看到了構建 CSS 的新方式的興起，比如 Yahoo 的 Atomic CSS 和 Adam Morse 的 Tachyons，它們更喜歡短小的，單一用途的類名，而不是語義化的類名。舉個例子，當使用 Atomic CSS 時，你將使用類似于函數調用的語法去作為類名，并且這些類名會在之后被用來生成合適的樣式表。

  Atomic CSS

通過最大程度地提高類的復用性以及用內聯樣式的方式一樣有效處理類名，可以達到盡可能地精簡 CSS 的目的。雖然文件大小的減少很容易體現，但對于你的代碼庫和團隊成員的影響確實是微乎其微的。這些優化會從底層引起你的 CSS 和標記語言的變化，使他們成為構建工作中更重要的部分。

正如我們已經介紹過的，當使用 CSS-in-JS 或者 CSS 模塊時，你不再需要在 HTML 中硬編碼你的類名，而是動態引用由庫或者構建工具自動生成的 JavaScript 變量。

我們這樣寫樣式:

而不是:

這個變化可能看起來相當膚淺，但是從如何管理標記語言和樣式之間關系上來說，這卻是一個里程碑式的改變。通過給我們的 CSS 工具不止修改樣式，還能修改最終提供給組件的 class 的能力，我們為我們的樣式表解鎖了一個全新的優化方式。

如果看看上面的例子，就會發現 "styles.sidebar" 對應了一個字符串，但并沒有什么去限制它只能是一個 class。就我們所了解的，它可以很容易的對應成表示十幾個 class 的字符串。

如果我們可以優化我們的樣式，為每一套樣式生成多個類，我們就可以做一些非常有趣的事。

我最喜歡的例子是 Ryan Tsao 編寫的 Styletron。

與 CSS-in-JS 和 CSS 模塊自動添加 BEM 風格前綴的過程相同，Styletron 對 Atomic CSS 也做了相同的事。

它的核心 API 專注于一件事，為每個由屬性、值、媒體查詢組合起來的樣式定義一個獨立的 CSS 規則，然后返回自動生成的 class。

import styletron from "styletron";
styletron.injectDeclaration({
  prop: "color",
  val: "red",
  media: "(min-width: 800px)"
});
// → "a"

當然，Styletron 也提供了一些高級 API，比如它的 injectStyle 函數允許一次定義多個規則。

import { injectStyle } from "styletron-utils";
injectStyle(styletron, {
  color: "red",
  display: "inline-block"
});
// → "a d"
injectStyle(styletron, {
  color: "red",
  fontSize: "1.6em"
});
// → "a e"

尤其要注意上面生成的類名之間的相同點。

通過放棄對 class 本身的低級控制，而僅定義所需要的樣式集合，這些庫就能幫我們生成最佳的 class 原子集合。

之前我們通過手工查找的方式將樣式分割成可復用的 class，現在已經可以完全自動化的完成這種優化了，并且你應該也開始注意到這個趨勢。原子性 CSS 已經烙在里面了，并非一個可選項。

在談論這一點之前，我們先停下來問自己一個看似簡單的問題。

我們如何共享 CSS？

我們已經從手動下載 CSS 文件向使用前端專門的模塊管理工具轉變，比如 Bower，或者現在通過 npm 可以使用 Browserify 和 webpack。雖然這些工具已經自動處理了外部模塊的 CSS 依賴，但是目前前端社區大多還是手工處理 CSS 的依賴關系。

無論使用哪種方式，CSS 之間的依賴都不是很好處理。

你們許多人可能還記得，在使用 Bower 和 npm 管理 JavaScript 模塊時，出現過類似的情況。

Bower 沒有依賴任何特定的模塊格式，而發布到 npm 的模塊則要求使用 CommonJS 模塊格式。這種不一致，對發布到兩者任何一個平臺的包的數量都產生了巨大的影響。

小型但是有復雜依賴關系的模塊更愿意使用 npm，Bower 則吸引了大量大型而獨立的模塊，當然，你可能也就有兩三個模塊，再加幾個插件，但由于在 Bower 中你的依賴沒有一個模塊系統去作支撐，每個包無法簡單的利用它自己的依賴關系，所以在整合這一塊，基本上就留給開發者手動去操作了。

因此，隨著時間的推移，npm 上的模塊數量呈指數性增長，而 Bower 只能是有限的線性增長。雖然這可能是各種原因導致的，但是不得不說，主要原因還是在于兩個平臺處理運行時包與包之間的依賴關系的不同方法。

很不幸，這對于 CSS 社區來說太熟悉了，我們發現相對于 npm 上的 JavaScript 來說，獨立 CSS 模塊的數量也增長的很慢。

如果我們也想實現 npm 的指數增長該怎么做？如果我們想依賴不同大小不同層次的復雜模塊，而不是專注于大型、全面的框架呢？為了做到這一點，我們不僅需要一個包管理器，還需要一個合適的模塊格式。

這是否意味著我們需要專門為 CSS 或者 Sass 和 Less 這樣的預處理器設計一個包管理工具？

有趣的是，在 HTML 上我們已經實現了類似的功能。如果你問我相同的問題：我們如何共享標記語言？你可能很快會想起來，我們幾乎不會直接共享原始的 HTML —— 我們共享 HTML-in-JS。

我們通過 jQuery 插件，Angular 指令集 和 React 組件實現了這個功能。我們的大組件由小組件組成，每一個小組件都有著自己的 HTML，它們也都獨立的發布在了 npm 上。HTML 這種格式可能不足以強大到完成這個功能，但是通過將 HTML 嵌入到完整的編程語言中，我們就可以很輕松的越過這個限制。

我們能不能像 HTML 那樣，通過 JavaScript 去分享 CSS呢？能不能使用函數來返回對象和字符串而不是使用 mixins ？又或者我們利用 Object.assign 和新的 object spread 操作符 來 merge 對象而不是用 extending classes 呢？

const styles = {
  ...rules,
  ...moreRules,
  fontFamily: "Comic Sans MS",
  color: "blue"
}

一旦我們開始用這種方式編寫我們的樣式，我們就可以使用相同的模式、相同的工具、相同的基礎架構、相同的生態系統來編寫和分享我們的樣式代碼，就像我們應用程序中的其他任何代碼一樣。

由 Max Stoiber、Nik Graf 和 Brian Hough 開發的 Polished 就是一個很好的例子。

Polished 就像是 CSS-in-JS 界的 Lodash，它提供了一整套完整的 mixins、顏色函數等等，使得在 JavaScript 中可以得到使用 Sass 編寫樣式的體驗。最大的區別在于，現在這些代碼在復用、測試和分享方面，都提高了一個層次，并且能夠完整的使用 JavaScript 模塊生態系統。

當談到 CSS 時我們會想，作為一個由小型可復用的開源模塊組合成的一個樣式集合，我們如何獲得和 npm 上其他模塊相似的開源程度？奇怪的是，我們最終通過將我們的 CSS 嵌入其他的語言并且完全擁抱 JavaScript 模塊實現了這一點。

到目前為止，我的文章已經涵蓋了所有的要點，雖然在 JavaScript 中編寫 CSS 會容易的多，但是常規的 CSS 并非完不成這些功能。這也是我把最有趣、最面向未來的一點留到現在的原因。這一點并不一定能在如今的 CSS-in-JS 社區中發揮巨大的作用，但它可能會成為未來設計的基礎層面。它不僅會影響開發人員，也會影響設計師，最終它將改變這兩個領域相互溝通的方式。

首先，為了介紹它，我們需要先簡單介紹一下 React。

—

React 的理念是用組件作為最終渲染的中間層。在瀏覽器中工作時，我們構建復雜的虛擬 DOM 樹而不是直接操作 DOM 元素。

有趣的是，DOM 渲染相關的代碼并不屬于 React 的核心部分，而是由 react-dom 提供的。

import { render } from "react-dom"

盡管最初 React 是為 DOM 設計的，并且大部分情況下還是在瀏覽器中使用，但是這種模式也允許 React 只通過簡單地引入新的渲染引擎就能從容面對各種不同的使用環境。

JSX 不僅僅可以用于虛擬 DOM，他可以用在任何的虛擬視圖上。

這就是 React Native 的工作原理，我們通過編寫那些渲染成 native 的組件以實現用 JavaScript 編寫真正的 native 應用，比如我們用 View 和 Text 取代了 div 和 span。

從 CSS 的角度來看，React 最有趣的就是它擁有自己的 StyleSheet API。

var styles = StyleSheet.create({
  container: {
    borderRadius: 4,
    borderWidth: 0.5,
    borderColor: "#d6d7da",
  },
  title: {
    fontSize: 19,
    fontWeight: "bold",
  },
  activeTitle: {
    color: "red",
  }
})

在這里你會看到一組熟悉的樣式，我們編寫了顏色、字體和邊框樣式。

這些規則都非常簡單，并且很容易映射到大部分的 UI 環境上，但是當涉及到 native 布局時，事情就變得非常有趣了。

var styles = StyleSheet.create({
  container: {
    display: "flex"
  }
})

因為在瀏覽器環境之外，所以 React Native 有自己的 flexbox 實現

最初發布時他是一個名為 css-layout 的JavaScript 模塊，完全用 JavaScript 重新實現了 flexbox（包含充分的測試），為了更好的可移植性它現在已經遷移到 C 語言。

鑒于這個項目的影響力和重要性，它被賦予了更重要的品牌 ——— Yoga。

雖然 Yoga 專注于將 CSS 遷移到非瀏覽器環境中，但是僅關注于 CSS 特性的一小部分無法擴大它的統治范圍。

"Yoga 的重點是成為一個有表現力的布局框架，而不是去實現一套完整的 CSS"

這看起來似乎很難實現，但是當你回顧 CSS 體系的歷史時會發現使用 CSS 進行規模化的工作就是選擇一個合適的語言子集。

在 Yoga 中，為了控制樣式的作用域，他們避開了級聯樣式，并且將布局引擎完全集中在 flexbox 上。雖然這樣會喪失很多功能，但它也為需要嵌入樣式的跨平臺組件創造了驚人的機遇，我們已經看到幾個試圖利用這個特性的開源項目。

Nicolas Gallagher 開發的 React Native for Web 旨在成為 react-native 的一個替代品。當使用 webpack 這類打包工具時，很容易用別名來替換第三方庫。

module: {
  alias: {
    "react-native": "react-native-web"
  }
}

使用 React Native for Web 后可以在瀏覽器環境中運行 React Native 組件，包括 React Native 樣式 API

同樣，Leland Richardson 開發的 react-primitives 也提供了一套跨平臺的原始組件，它可以抽象目標平臺的實現細節，為跨平臺組件創造可行的標準。

甚至 微軟 也開始推出 ReactXP，這個庫旨在簡化跨 web 和 native 的工作流，它也有自己的跨平臺樣式實現

—

即使你不編寫 native 應用程序，也要注意一點：擁有一個真正的跨平臺組件抽象，能夠使我們將目標設定在那些高效的、無限可能的環境中去，有時這些會讓你無法想象。

我所見過的最令人震驚的例子是 Airbnb 的 Jon Gold 開發的 react-sketchapp。

我們很多人都花費了大量時間去嘗試標準化我們的設計語言，并且盡可能的避免系統中的重復。不幸的是，盡管我們希望樣式只有一個來源，但我們最多也只能減少到兩個，開發人員的動態樣式以及設計師的靜態樣式。雖然這已經比我們之前的模式好了很多，但是它仍然需要我們手工的將樣式從 Sketch 這樣的設計工具上同步到代碼里。這也是 react-sketchapp 被開發出來的原因。

感謝 Sketch 的 JavaScript API，以及 React 連接到不同渲染引擎的能力，react-sketchapp 讓我們可以用跨平臺的 React 組件渲染我們的 Sketch 文件。

不用多說，這很可能改變設計師和開發人員的合作方式。現在，當我們對設計進行迭代時，無論在設計工具還是開發者工具上，我們都可以通過相同的聲明引用同一個組件。

通過 Sketch 中的符號和 React 中的組件，我們的行業已經開始從本質上趨于抽象，并且通過使用相同的工具我們可以更緊密的協作。

這么多新的嘗試都來自 React 和其周邊的社區，看來這并不是巧合。

在組件架構中，最重要的是將組件的功能集中在一起。這自然包括它的局部樣式，往更復雜的方向延伸就涉及到數據的獲取。這里要感謝 Relay 和 Apollo，讓這個過程變得簡單。這些成果解鎖了巨大了潛力，我們現在所了解的，只是其中冰山一角。

雖然這對我們編寫樣式產生了很大的影響，但其實它對我們架構里的一切都有很大的影響，當然，是出于好的理由。

通過統一單一語言開發組件的模式，我們能夠從功能上，而不是從技術上，將我們的關注點進行更好的隔離。將組件的所有內容局部化，用他們構建大型可維護的系統，用之前無法使用的方式進行優化，更容易的分享我們的工作，以及利用小型開源模塊構建大型應用程序。更重要的是，完成這一切并不需要打破漸進增強的理念，也不會讓我們放棄認真對待 web 平臺的理念。

最重要的是，我對使用單一語言編寫出的組件的潛力感到興奮，他們形成了一種新的、統一的樣式語言基礎，以一種前所未有的方式統一了前端社區。

在 SEEK，我們正在努力利用這一功能，我們圍繞組件模型來構建在線樣式指南，其中語義化、交互性和視覺風格都有統一的抽象。這構成了開發人員和設計師之間共享的通用設計語言。

構建一個頁面應該盡可能的和拼裝組件一樣簡單，這樣可以確保我們工作的高品質，并且讓我們在產品上線很久以后，也有能力去升級其設計語言。

import {
  PageBlock,
  Card,
  Text
} from "seek-style-guide/react"
const App = () => (
  
    
      Hello World!
    
  
)

盡管我們現在使用 React，webpack 和 CSS 模塊構建了這個樣式指南，但是這個架構，和任何你之前知道的 CSS-in-JS 系統是一致的。技術上可能不一致，但是核心理念是一樣的。

然而，未來這些技術選型可能也需要以一種意想不到的方式進行轉變，這也就是為什么保持對這個領域的持續關注，對與我們不斷發展的組件生態是如此的重要。我們現在可能不會用 CSS-in-JS 這項技術，但是很可能沒過多久就會出現一個令人信服的理由讓我們使用它。

CSS-in-JS 在短時間里有了出人意料的發展，但更重要的是，它只是這個宏偉藍圖的開始。

它還有很大的改進空間，并且它的創新還沒有停止的跡象。新的庫正不斷涌現，它們解決了未來會出現的問題并且提升了開發人員的體驗 —— 比如性能的提升，在構建時抽取靜態 CSS，支持 CSS 變量以及降低了前端開發人員的入門門檻。

這也是 CSS 社區關注的地方。盡管這些對我們的工作流程有很大的改動，但是他們不會改變你仍然需要學習 CSS 的事實。

我們可能使用不同的語法，也可能以不同的方式構建我們的應用，但是 CSS 的基本構建塊不會消失。同樣，我們行業向組件架構的轉變是不可避免的，通過這種方式重新構想前端的意愿只會越來越強烈。我們非常需要共同合作以確保我們的解決方案廣泛適用于各種背景的開發人員，無論是專注于設計的還是工程的。

雖然有時我們的觀點不一致，但是 CSS 和 JS 社區對于改進前端，把 Web 平臺變得更加重要以及改進我們下一代 web 開發流程都有很大的激情。社區的潛力是巨大的，而且盡管到目前為止我們已經解決了大量的問題，仍然有很多工作還沒有完成。

到這里，可能你還是沒有被說服，但是完全沒關系。雖然現在在工作上使用 CSS-in-JS 不是很合適，但我希望它有合適的原因，而不是僅僅因為語法就反對它。

無論如何，未來幾年這種編寫樣式的風格可能會越來越流行，并且值得關注的是它發展的非常快。我衷心希望你可以加入我們，無論是通過貢獻代碼還是簡單的參與我們的對話討論，都能讓下一代 CSS 工具盡可能的提高前端開發人員的工作效率。或者，我希望已經讓你們至少了解為什么人們對這一塊如此飽含激情，或者，至少了解為什么這不是一個愚蠢的點子。

掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區，文章來源為 掘金 上的英文分享文章。內容覆蓋 Android、iOS、React、前端、后端、產品、設計 等領域，想要查看更多優質譯文請持續關注 掘金翻譯計劃。