前言
关注点分离（separation of concerns）原则多年来大行其道，实践中一般将 html、CSS、javascript 分开编写维护，早期框架 angularjs 即是如此，直到 React 争议中问世，引领关注点混合趋势，驱使开发者重新审视 CSS 工程化发展。
尴尬的CSS
相对于 JavaScript 的突飞猛进，CSS 的发展缓慢，相对止步不前。随着前端职能扩大化成为常态，前端工程化日趋成熟，CSS 先天缺陷愈发明显：
- 全局作用域
- 缺乏高级编程特性
- 代码冗余
- 极限压缩
- 依赖管理
最大的缺陷 来自于全局作用域，class name 全局生效，多人协作中的风格不一致，随时可能引发蝴蝶效应。为规避多人协作的风格冲突，社区提出 OOCSS，BEM 等方法论，但实践中完全取决于团队执行力度，笔者也曾苦恼于合理的命名，为避免冲突，导致类名冗长，无聊且痛苦。
缺乏高级编程特性 影响同样深远，社区发展的预处理器能够有效缓解，sass，less，stylus殊途同归，postcss 异军突起，基本实现变量、嵌套、变量、混合、扩展和逻辑等。随着 CSS 规范逐步推进，高级编程特性完全可期。笔者大胆断言，前端工程化的推进，已经基本解决 CSS高级编程特性缺乏 的问题。
代码冗余，极限压缩对开发的影响相对很小，经典的 bootstrap 就包含大量的冗余代码，但丝毫不影响其流行程度。
目前难以解决的是依赖管理，NPM 已经成为事实上的 JavaScript 包管理工具，而 CSS 始终没有发展出可用的管理模式，sass 的浅尝辄止，例如 bootstrap-sass, Bourbon等，显然无法满足需求。随着 React 引领的关注点混合，以组件为核心的开发模式，有效规避了 CSS 缺乏依赖管理的缺陷，笔者认为，依赖管理弊端完全可控，未来的发展，留给未来述说。
新锐的组件化
前端发展日新月异，React 在众人争议中进入视野，典型的 React 组件同时包含结构、样式、行为，示例如下：
/**
* @description - lite component
* @author - huang.jian <hjj491229492@hotmail.com>
*/
export class Counter extends Component {
constructor(props) {
super(props);
this.state = {
timestamp: Date.now()
};
}
render() {
return (
<Card title="React Timestamp">
<Alert message={`React Timestamp: ${this.state.timestamp}`} type="success"/>
<Alert message={`React Timestamp: ${this.state.timestamp}`} type="info"/>
<Alert message={`React Timestamp: ${this.state.timestamp}`} type="warning"/>
</Card>
);
}
}前端应用由组件聚合而成，组件层面对 CSS 进行抽象，从而解决大型应用的 CSS 维护难题。社区出现的 CSS IN JS 解决方案，目前看来就是可行解决方案，其本质在于通过 JavaScript 来声明，维护样式，以 styled-components 举例：
const Button = styled.button`
border-radius: 3px;
padding: 0.25em 1em;
color: palevioletred;
border: 2px solid palevioletred;
`;
function Buttons() {
return (
<Button>Normal Button</Button>
<Button primary>Primary Button</Button>
);
}样式寄生组件之中，组件挂载时，动态插入样式，实现按需加载，动态生成类名，隔离作用域。另外一种思路，通过 style 属性传入内嵌样式，完全规避选择器全局作用域的问题。
// 官方示例有删减
var Radium = require(‘radium‘);
var React = require(‘react‘);
var color = require(‘color‘);
// You can create your style objects dynamically or share them for
// every instance of the component.
var styles = {
base: {
color: ‘#fff‘,
},
primary: {
background: ‘#0074D9‘
},
warning: {
background: ‘#FF4136‘
}
};
@Radium
class Button extends React.Component {
render() {
return (
<button
style={[
styles.base,
styles[this.props.kind]
]}>
{this.props.children}
</button>
);
}
}面向组件开发，为样式管理提供更多的可能性，完全使用 JavaScript 抽象，管理，维护样式，略显激进，但也不失为一种解决方案。
客观的分析
目前主流的 CSS IN JS 方案与传统的方式对比如下：
优势：
- 隔离作用域 -- 样式生效通过内嵌，或者生成独一无二的类名，避免出现选择器冲突；
- 高级编程特性 -- 充分利用 JavaScript 的能力增强对样式的控制；
- 样式按需挂载 -- 页面需要的样式才会加载，有效避免样式冗余；
- 依赖管理 -- 寄生于组件，利用现存的
NPM生态进行包管理； - 动态样式 -- 能够更加简单，直接的修改样式
劣势：
- 无法复用现有生态，特性完全依赖于库的实现；
- 编辑器代码补全，语法检查，语法高亮等需要插件支持；
- 伪类选择器（
disabled、:before、:nth-child）支持诡异； - 样式属性骆驼式命名；
独辟蹊径
笔者并不完全认同 CSS IN JS 的理念，也不反对将其应用于生产项目。CSS 中最严重的问题，不通过 CSS-in-JS 也能
有其他解决方案，也就是笔者当前使用的 CSS Module 方案。通过工程化的方式，将选择器编译为独一无二的类名，使用 JavaScript 管理选择器与元素的关联，仅此而已。
// Header.jsx
import style from ‘./Header.css‘
// { header: ‘Header__header--3kSIq_0‘ }
export default function Header() {
return (<div className={style.header}>Header!!!</div>);
}优势：
- 隔离作用域 -- 类名编译生成，有效避免选择器冲突；
- 样式按需加载 -- 利用
tree-shaking机制，仅保留存在引用的选择器，有效避免样式冗余； - 依赖管理 -- 关联组件，利用现存的
NPM机制进行包管理； - 充分利用现有生态 -- 编辑器高亮，自动补全，
sass，postcss高级编程特性；
劣势：
- 欠缺动态样式特性 -- 无法充分利用 JavaScript 的能力增强对样式的控制；
主观的感悟
本文未涉及的 单文件组件 也是可行方案之一，目前 Vue，Angular 等框架采用。笔者始终认为，与其创造更多抽象的技术让前端学习曲线更加陡峭，不如通过工程化的手段来修复存在的缺陷，理念上求同存异。面对各种技术方案，适合实际项目的方案才是最好的方案，选用预处理器 PostCSS，BEM，亦或动态编译，都需要结合业务场景、团队习惯等因素决策。
关注公众号，获取动态，支持作者。
