有些人极为讨厌CSS-in-JS，单单提起这个名字都会让他们反感，总之就是拒绝二字。他们认为样式不属于JavaScript，而是属于CSS，并且CSS有着很长的历史，浏览器支持非常完善。关注点必须分离，其他路子都走错了，我们要以史为鉴（比如标签等）。

有些人非常喜欢CSS-in-JS。他们看到模板和功能并存的理念和大多数的JavaScript框架都非常成功，所以包装在样式里似乎就是顺其自然。Vue的单文件组件就是一个例子。

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

CSS-in-JS能做什么？

CSS-in-JS没法让你了解：

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：

Max Stoiber写的文章介绍了这种方法给他带来的信心和为他节省的时间。但他也认为这种方法只适合JavaScript框架应用程序。

如果你使用JavaScript框架来构建包含组件的Web应用程序，那么CSS-in-JS可能非常适合你的需求。如果你的团队成员都具备基本的JavaScript能力那就最好不过了。

CSS-in-JS 是恶魔还是天使？