译者 | 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/
活动推荐GMTC 全球大前端技术大会首次落地华南，走入大湾区深圳。
往届他们请到了来自 Google、Twitter、Instagram、阿里、腾讯、字节跳动、百度、京东、美团等国内外一线公司的顶级前端专家，分享了关于小程序、Flutter、Node、RN、前端架构、前端安全、前端工程化、移动 AI 等 50 多个热门技术专题。目前深圳站正式启动，7 折最低价售票通道已经开启，详细请咨询：13269078023（同微信）。
